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This  thesis  explores  the  addition  of  Artificial  Intelligence  (Al)  capability  to 
the  DeltaSD  Gaming  and  Simulation  engine  developed  at  the  Naval  Postgraduate 
School.  A  look  at  what  types  of  Al  capabilities  exist  and  their  potential  to  add 
value  to  the  project  is  presented.  This  look  includes  the  use  of  specific  Al 
technologies,  such  as  State  Machines  and  Pathfinding,  as  well  as  the  potential 
use  of  existing  open  source  packages.  One  growing  trend  in  the  commercial 
game  industry  is  the  use  of  Al  Middleware  packages,  allowing  developers  to  buy 
what  technologies  they  need  and  reduce  development  time.  This  thesis  covers 
the  link  between  Al  and  animation,  specifically  comparing  how  animation  is 
handled  by  DeltaSD  and  UnrealEngine.  One  final  area  covered  is  the  use  of 
scripting  to  generate  behaviors  within  a  game  or  simulation.  Again, 
UnrealEngine,  specifically  UnrealScript,  is  considered  as  a  potential  model  for  a 
scripting  language  based  on  the  Python  programming  language.  Python  was 
chosen  based  on  its  integration  with  the  underlying  C++  base  code.  By  following 
the  game  industry’s  lead,  one  has  a  pool  of  potential  options  and  avoids 
attempting  to  reinvent  the  wheel. 


V 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


VI 


TABLE  OF  CONTENTS 


I.  INTRODUCTION . 1 

A.  THESIS  STATEMENT . 1 

B.  MOTIVATION . 1 

C.  THESIS  ORGANIZATION . 4 

II.  BACKGROUND . 5 

A.  INTRODUCTION . 5 

B.  SOME  COMMON  GAME  ENGINE  TERMINOLOGY . 5 

1.  Game  Engine . 5 

2.  Non  Player  Character . 6 

3.  Scripting  Language . 7 

C.  CURRENT  STATE  OF  THE  ART  ENGINES . 7 

D.  DIFFERENCES  IN  Al  FOCUS . 9 

1.  Game  Industry . 10 

2.  Department  of  Defense . 1 1 

E.  SUMMARY . 12 

III.  COMMON  Al  CAPABILITIES . 13 

A.  INTRODUCTION . 13 

B.  GAME  Al  CAPABILITIES  AND  TECHNOLOGIES  IN  USE  TODAY..  13 

1.  Pathfinding . 14 

2.  Dead  Reckoning . 14 

3.  State  Machines . 15 

a.  Finite  State  Machine  (FSM) . 15 

b.  Stack-Based  State  Machine . 16 

c.  Fuzzy  State  Machine  (FuSM) . 16 

4.  Line  of  Sight . 16 

5.  Scripting . 17 

C.  OPEN-SOURCE  Al  PACKAGES . 18 

1.  OpenAI . 19 

2.  Flexible  Animat  Embodied  aRchitecture  (FEAR) . 19 

D.  Al  MIDDLEWARE . 20 

E.  Al  AND  ANIMATION . 24 

1.  Animation  in  Unreal . 24 

2.  Animation  in  Delta3D . 25 

F.  SUMMARY . 27 

IV.  SCRIPTING  LANGUAGES . 29 

A.  INTRODUCTION . 29 

B.  PROGRAMMING  LANGUAGE  BACKGROUND . 29 

C.  COMMON  LANGUAGES  IN  USE  TODAY . 31 

1.  Python . 32 

2.  Lua . 33 

vii 


3.  UnrealScript . 33 

D.  APPLICATION  TO  A  GAME  ENGINE . 34 

1.  UnrealScript  in  Unreal  Engine . 34 

2.  Python  in  Delta3D . 35 

a.  Sample  Python  Script . 35 

b.  Integrating  Python . 37 

E.  SUMMARY . 42 

V.  CONCLUSIONS  AND  FUTURE  WORK . 43 

A.  INTRODUCTION . 43 

B.  CONCLUSION . 43 

1.  Common  Al  Technologies . 44 

a.  State  Machine . 44 

b.  Pathfinding . 45 

c.  Scripting . 45 

2.  Open-Source  Al  Packages . 45 

3.  Al  Middleware . 46 

4.  Al  and  Animation . 46 

C.  FUTURE  WORK . 47 

1.  N PCs  Using  Python  Script . 47 

2.  Interface  with  Production  Systems . 47 

3.  Define  an  Objective  Measure . 48 

4.  Cost/Benefit  Analysis . 48 

5.  Al  on  a  Dedicated  Processor . 49 

LIST  OF  REFERENCES . 51 

INITIAL  DISTRIBUTION  LIST . 53 


viii 


LIST  OF  FIGURES 


Figure  1 .  A  Finite  State  Machine  Example.  (From:  WikiOS) . 15 

Figure  2.  Al  Middleware  Block  Diagram  (From:  DybsandOS) . 22 

Figure  3.  Code  Snippet  from  NPSbot-Flee  from  MV4025  Course  Materials . 25 

Figure  4.  Code  Snippet  from  marine. rbody  from  Delta3D/data/marine/ . 27 

Figure  5.  Compiling  Process  taken  from  Game  Programming  with  Python, 

Lua,  and  Ruby  (From:  Gutschmidt04) . 30 

Figure  6.  Code  Snippet  from  NPSbot-Flee  from  MV4025  Course  Materials . 34 

Figure  7.  Code  Snippet  from  testpython.py . 35 

Figure  8.  Resulting  Application  from  Python  Script . 37 

Figure  9.  Sample  Python  Bindings . 38 

Figure  10.  Code  Snippet  from  character.h . 38 

Figure  1 1 .  Code  from  animate. py . 40 

Figure  1 2.  Running  the  TestPythonChar  Application . 41 

Figure  13.  Running  the  animate. py  Python  Script . 42 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


X 


LIST  OF  TABLES 


Table  1.  Scripting  Influence  Spectrum.  (From:  Rabin04) . 18 

Table  2.  Al  Middleware  Comparison  Matrix  compiled  from  (From: 

DybsandOS) . 23 


XI 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


XII 


ACKNOWLEDGMENTS 


There  are  many  people  to  thank  for  their  support  in  the  completion  of  this 
thesis.  In  no  particular  order: 

Dr.  Christian  Darken:  thesis  advisor.  Thank  you  for  some  excellent 
learning  experiences  in  the  many  classes  I  took  with  you  and  increasing  my 
interest  in  the  general  field  of  Artificial  Intelligence.  Thank  you  for  your  patience 
with  me.  It  is  my  sincere  hope  that  the  results  of  this  evaluation  can  be  carried 
forward  to  the  implementation  of  Al  in  DeltaSD. 

Dr.  Rudy  Darken:  Academic  Associate  and  current  MOVES  Institute 
Director.  Thank  you  for  being  a  source  of  incredible  enthusiasm  and  ideas. 

CDR  Joseph  Sullivan:  Program  Officer.  Thank  you  for  your  mentorship 
and  leadership  during  my  time  here. 

The  DeltaSD  team:  Erik  Johnson,  Chris  Osborn  and  Matt  Prichard.  Thank 
you  for  all  the  help  and  support,  especially  to  Chris  Osborn  over  the  last  few 
months.  Thanks  for  patiently  answering  my  questions;  even  the  ones  that  were 
in  the  README  file. 

My  amigos:  Joaquin  S.  Correia,  Louis  Gutierrez,  Murat  Onder,  and  Oliver 
Tan.  Steve,  thanks  for  being  a  great  roommate  and  putting  up  with  me  for  2 
years.  Congratulations,  you  survived!  Lou,  thanks  for  all  your  help  and 
psychoanalysis,  but  mostly  your  friendship.  Murat,  thanks  for  all  your  help  early 
on  in  the  curriculum.  I  owe  a  lot  to  you.  And  last  but  not  least,  Oliver.  Thanks 
for  your  help  during  the  agents  class. 

Prior  and  current  MOVES  students.  Thanks  to  those  who  went  before  me 
and  to  those  students  who  have  2,  4,  or  6  quarters  left  to  go. 

Lt  Col  Karl  Pfeiffer,  USAF.  Thank  you  for  all  your  guidance  and  help. 

To  anyone  I  may  have  forgotten  to  list  by  name,  thank  you! 

xiii 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


XIV 


I.  INTRODUCTION 


A.  THESIS  STATEMENT 

One  common  feature  found  in  popular  game  engines  today  is  how 
believable  the  Artificial  Intelligence  (Al)  of  a  Non  Player  Character  (NPC)  appears 
to  the  player.  When  the  Al  of  a  game  is  not  believable,  it  is  often  perceived  by  a 
player  as  being  “dumb”  or  unintelligent.  In  this  situation,  a  player  often  prefers 
directly  competing  against  other  human  players  either  in  a  Local  Area  Network  or 
over  the  Internet. 

Similarly,  in  a  military  simulation,  it  is  often  desirable  to  train  with  or 
against  other  human  participants.  When  the  training  task  requires  multiple 
participants  and  not  all  are  available,  then  some  form  credible  Al  capability  is 
needed.  Recognizing  this  need,  it  is  good  engineering  practice  to  look  at  what 
other  commercial  game  engines  are  doing  with  respect  to  Al.  Using  that  as  a 
starting  point,  one  can  define  what  constitutes  minimum  functionality,  and  then 
build  from  there.  Or,  said  another  way,  the  capabilities  found  in  commercial 
game  engines  will  form  the  baseline  of  current  military  requirements,  as 
appropriate. 

B.  MOTIVATION 

In  an  effort  to  apply  entertainment  type  technology  to  military  applications, 
the  DeltaSD  project,  a  product  of  the  Modeling,  Virtual  Environments  and 
Simulations  (MOVES)  Institute  at  the  Naval  Postgraduate  School  (NPS),  is 
building  a  game  and  simulation  engine  using  readily  available  open  source 
software  tools  and  libraries.  The  goal  of  the  project  is  to  develop  a  full-featured 
open  source  gaming  and  simulation  engine  based  on  existing  open  source 
software.  In  its  current  version  DeltaSD  uses  the  following  open  source  projects: 
OpenSceneGraph  for  graphics  and  scene  rendering,  found  at 
http://www.opensceneqraph.orq/  (OSG05);  Open  Dynamics  Engine  for  physics 
simulation,  found  at  http://ode.orq/  (ODE05);  CalSd  for  character  animation. 
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found  at  http://cal3d.sourceforqe.net/  (Cal3d05)  and  OpenAL  for  sound,  found  at 
http://www.openal.orq/  (OpenALOS).  Going  the  open  source  route  avoids  the 
high  costs  associated  with  the  licensing  of  current  game  engine  technologies 
such  as  the  Unreal  Engine  of  Epic  Games™.  By  making  the  source  code 
available,  it  is  hoped  that  a  vibrant  developer  community  will  form  to  both  support 
and  enhance  the  Delta3D  engine.  In  return,  the  military  stands  to  gain  a 
continuously  updated  simulation  and  training  tool  and,  most  importantly,  one  that 
it  can  freely  use  and  repurpose  for  any  and  all  applicable  training  needs. 

The  Unreal  engine  is  one  of  the  most  successful  game  engines  available 
on  the  market  today  in  the  first  person  shooter  genre.  Not  only  does  Epic  Games 
produce  their  game  Unreal  Tournament  with  it,  but  other  game  development 
houses  license  the  Unreal  engine  to  produce  commercially  available  games. 
Some  examples  include  Tom  Clancy’s  Rainbow  Six:  Raven  Shield  by  Ubisoft  and 
Shadow  Ops™:  Red  Mercury  by  Atari,  Inc.  Similarly,  the  Army  Game  Project  at 
NPS  paid  for  the  license  to  use  the  Unreal  Engine  in  the  development  of 
America’s  Army.  Game  engines  in  general  are  quite  costly  to  develop,  so  some 
of  the  more  successful  ones  like  Unreal  are  used  to  generate  additional  revenue 
via  licensing  their  gaming  technologies. 

Over  the  past  few  years,  the  military  has  grown  more  receptive  to  the  use 

of  game  technology  for  training.  More  specifically,  the  U.S.  Army  created 

America’s  Army:  Operations  as  a  public  relations  exercise  and,  ultimately,  using 

it  as  a  potential  recruiting  tool.  Since  its  release  in  the  summer  of  2002,  interest 

in  using  it  for  training  has  increased.  However,  to  repurpose  America’s  Army  for 

a  specific  training  objective  requires  additional  licensing  costs  and  is  subject  to 

many  restrictions  on  its  potential  distribution.  The  Delta3D  project  was  created  to 

break  this  model.  In  the  commercial  world,  the  object  is  to  make  money  on  the 

games  created.  Since  the  military  is  not  selling  the  game  or  simulation  and  the 

target  volume  of  users  is  much  lower  than  the  market  of  a  popular  first-person 

shooter  game,  the  high  licensing  costs  make  the  use  of  commercial  gaming 

engines  undesirable.  With  the  Delta3D  engine  being  freely  available,  the  military 

can  make  many  training  specific  applications  and  distribute  it  to  any  and  all 
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commands  as  it  sees  fit.  The  main  costs  involved  presently  include  funding  of 
the  small  full-time  developer  team.  As  the  engine  matures  more,  it  should  gain 
more  open  source  developer  support  and  not  necessarily  require  a  huge 
expenditure. 

The  Unreal  Tournament  series  and  the  Unreal  Engine  provide  an 
appropriate  model  for  comparison  to  the  current  DeltaSD  engine.  In  fact,  in  a 
document  prepared  for  the  Naval  Education  and  Training  Command  (NETC)  in 
November  2004,  entitled  Game  Engine  Comparison  Table,  specifically  uses 
Unreal  as  a  basis  for  comparison  with  the  P-51  project  (now  called  DeltaSD) 
(Darken04).  By  using  the  Unreal  engine  as  a  basis  for  comparison,  one  can  see 
that  the  DeltaSD  project  is  steadily  progressing  on  the  way  to  producing  similar 
functionality  but  without  the  high  costs  and  licensing  restrictions.  However,  there 
are  two  specific  areas  that  need  to  be  developed  to  more  closely  match  the 
functionality  available  with  the  Unreal  Engine:  Networking  support  (both  local  and 
wide  area)  and  Artificial  Intelligence  (Al). 

Lacking  networking  support  in  a  game  or  training  product,  one  is  left  with 

only  a  single  player  mode.  Generally  speaking,  single  player  games  hold  little  or 

no  entertainment  value  without  some  form  of  Al  to  play  against.  In  the 

application  of  game  technology  to  training,  a  single  player  game  might  be  most 

appropriate  for  a  partial  task  trainer  like  the  DeltaSD  Fire  Fighter  trainer. 

However,  except  for  very  small  fires,  it  is  highly  likely  that  the  trainee  would  be 

part  of  a  fire  fighting  team.  In  extending  this  example  to  include  team  training, 

the  ability  to  participate  in  a  multi-participant  simulation  or  game  over  either  a 

local  or  wide  area  network  is  needed.  Networking  capability  facilitates  training 

with  all  the  members  of  the  team.  This  example  represents  an  ideal  situation; 

however,  it  might  not  be  possible  for  all  of  the  members  of  the  team  to  be 

present.  In  an  example  where  one  is  training  against  an  adversary,  there  might 

not  be  enough  human  participants  with  the  necessary  expertise  to  play  such  a 

role.  In  either  case,  a  game  or  simulation  should  have  some  form  of  credible  Al 

to  fill  in  where  human  players  are  not  readily  available.  To  be  engaging  for  a 

player  in  a  game  or  a  trainee  in  a  simulation  and  to  invoke  a  sense  of  immersion, 
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a  game  or  simulation  needs  the  ability  to  accommodate  multiple  participants, 
whether  they  are  human  opponents  or  software-based  agents  that  attempt  to 
mimic  realistic  human  behavior. 

Recognizing  the  need  to  incorporate  networking  and  Al  is  just  a  first  step. 
This  thesis  will  look  at  the  existing  game  and  simulation  engines,  specifically  with 
respect  to  Al,  and  recommend  some  baseline  requirements  for  the  immediate 
future.  By  incorporating  common  Al  functionality  found  in  existing  games,  a  more 
conducive  environment  to  continually  improve  and  create  content  for  the  DeltaSD 
engine  is  possible.  The  addition  of  Al  capabilities  will  add  another  level  of 
realism  beyond  the  visual  capabilities  of  the  existing  DeltaSD  engine. 


C.  THESIS  ORGANIZATION 

The  remainder  of  this  thesis  is  organized  as  follows: 

•  Chapter  II:  Background.  This  chapter  will  briefly  define  a  game 
engine  and  then  talk  more  about  the  current  state  of  the  art  in  the 
game  industry  and  Department  of  Defense.  It  will  also  briefly 
discuss  why  artificial  intelligence  is  important  and  highlight 
differences  between  the  two  domains. 

•  Chapter  III:  Elements  of  a  Successful  Engine.  This  chapter  will 
discuss  some  of  the  common  Al  technologies  used  in  today’s 
games.  It  will  also  talk  about  the  role  of  Al  with  respect  to 
animation.  Specifically  it  will  address  the  role  of  scripting 
languages  in  controlling  animation. 

•  Chapter  IV:  Scripting  Languages.  This  chapter  will  look  at  some 
of  the  common  scripting  languages  in  use  today.  Then  it  will  focus 
on  some  advantages  of  scripting  languages  and  why  scripting 
languages  are  suitable  for  Al. 

•  Chapter  V:  Conclusions  and  Future  Work.  This  chapter  will 
discuss  some  general  conclusions  and  provide  some  suggestions 
for  future  research. 
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II.  BACKGROUND 


A.  INTRODUCTION 

In  this  chapter,  a  brief  familiarization  with  game  technology  is  presented. 
Some  common  terms  used  in  the  game  industry  are  defined  and  a  look  at  the 
current  state  of  the  art  is  considered.  The  other  major  theme  of  this  chapter  is  to 
discuss  the  importance  of  Al  to  the  game  industry  and  the  Department  of 
Defense  (DoD).  Finally,  a  brief  look  at  where  game  and  DoD  needs  differ  is 
provided. 

B.  SOME  COMMON  GAME  ENGINE  TERMINOLOGY 

For  those  not  familiar  with  the  game  industry,  a  brief  discussion  of  some 
common  game  terminology  is  prudent.  As  in  any  technical  field,  the  game 
industry  comes  complete  with  its  own  unique  jargon.  In  addition,  in  the  right 
context,  game  and  simulation  may  be  considered  interchangeable  terms. 
Unfortunately,  there  exists  a  somewhat  negative  connotation  attached  to  the 
word  “game.”  However,  as  more  game  technologies  are  appropriately  and 
successfully  used  in  training  and  simulations,  this  attitude  should  change. 

1.  Game  Engine 

Probably  the  most  commonly  used  term  in  this  thesis  is  game  engine. 
What  is  a  game  engine?  More  often  than  not,  many  mistake  the  entire  game  for 
the  game  engine.  One  possible  analogy  is  that  of  a  car  and  a  car  engine.  It  is 
possible  to  take  a  car  engine  out  and  build  another  body  to  put  around  it. 
Similarly,  the  game  engine  is  the  basic  unit  for  non-game  specific  things,  like  the 
rendering  system.  The  game  engine  will  always  handle  how  objects  in  a  game 
are  drawn  to  the  screen.  On  the  other  hand,  the  game  on  top  of  the  game 
engine  is  made  up  of  content.  This  would  include  things  like  the  models 
(vehicles,  buildings  or  characters),  the  animations,  sounds,  Al  and  even  physics. 
Initially  it  might  seem  like  physics  is  something  that  would  be  part  of  the  engine; 
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however,  it  would  be  possible  to  envision  a  game  engine  being  reused  for  a  flight 
simulator.  In  such  a  case,  the  physics  of  say  a  first  person  shooter  type  game 
wouldn’t  necessarily  make  sense,  and  instead  a  physics  model  for  aerodynamics 
would  be  appropriate.  (Simpson02) 

2.  Non  Player  Character 

Another  common  term,  specifically  in  relationship  to  Al,  is  Non  Player 
Character,  or  NPC.  Any  character  in  a  game  that  is  not  controlled  by  a  human 
player  is  a  Non  Player  Character.  Often  the  NPC  is  one  of  the  most  obvious 
places  in  a  game  where  Al  manifests  itself.  NPCs  can  be  either  friend  or  foe.  In 
a  team  based  setting,  NPCs  or  human  players  can  act  as  members  of  the  team. 
On  the  other  hand,  NPCs  can  also  act  in  an  adversarial  role.  An  example  might 
be  a  force  on  force  exercise.  If  the  goal  is  to  capture  the  enemy  flag,  and  the 
enemy  has  three  team  members,  the  game  would  create  three  NPCs  to  act  as 
the  adversaries  and  use  some  form  of  team  Al  for  that  type  of  game. 

NPCs  from  any  game  consist  of  essentially  two  parts:  a  body  and  a 
controller.  The  body  is  the  physical  appearance  of  the  NPC  or  ‘bot.  The  term  bot 
is  also  used  quite  often  in  the  game  world.  Bot  is  short  for  robot.  In  a  sense,  the 
character  is  like  a  robot.  Though  that  name  may  not  quite  adequately  describe 
NPCs  today,  it  is  commonly  used.  The  body  could  be  a  human  form,  or  some 
type  of  alien  life  form.  Furthermore,  a  bot  is  not  necessarily  limited  to  a  human 
form.  It  could  possibly  take  other  common  forms  such  as  tanks,  planes,  or  even 
ships.  Its  representation  in  the  game  is  limited  in  part  by  developer  imagination 
and  part  by  the  number  of  polygons  that  make  up  the  model.  Complex  models 
have  hundreds  of  thousands  to  millions  of  polygons.  Having  a  large  number  of 
NPCs  with  a  high  polygon  count,  developers  run  the  risk  of  limiting  what  the 
game  engine  can  handle.  This  is  a  function  of  the  current  technology  and  its 
limitations,  which  as  technology  marches  on  becomes  less  important.  The  other 
part  of  the  NPC  is  a  controller.  In  a  sense,  one  can  think  of  the  controller  as  the 
brain  of  the  NPC.  It  is  here  where  the  Al  is  contained.  The  controller  senses  its 

environment  in  whatever  ways  the  designer  has  called  for,  makes  a  decision  on 
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how  to  act  and  then  executes.  In  better-designed  Al,  the  resulting  actions  hint  at 
intelligent  control.  In  the  end,  Al  is  still  a  rather  difficult  science  problem  but 
leaves  plenty  of  avenues  to  explore. 


3.  Scripting  Language 

One  possible  definition  of  a  scripting  language  is  “any  programming 
language  that  is  created  to  simplify  a  complex  task  for  a  particular  program.” 
(Berger02)  A  scripting  language  in  a  first-person  shooter  game  might  be  used  to 
define  the  Al  of  any  of  the  various  NPCs  that  appear.  Similar  to  the  relationship 
between  game  and  game  engine,  a  scripting  language  is  generally  broken  up 
into  two  parts:  the  scripting  language  and  the  scripting  engine.  The  language  is 
the  scriptwriter’s  interface  to  the  underlying  scripting  engine.  Like  almost  any 
programming  language,  it  has  a  specific  syntax  and  structure  and  the  scripts  are 
run  through  a  compiler  to  be  translated  to  a  format  that  the  scripting  engine  can 
handle.  The  engine,  also  called  an  interpreter,  takes  the  compiled  script  and 
executes  it.  This  compiled  script  is  called  a  bytecode  stream,  which  contains 
everything  needed  to  execute  the  script.  More  complicated  scripting  languages 
often  take  a  long  time  to  compile,  so  the  compile  is  often  performed  before  to 
reduce  this  overhead.  (Berger02)  It  is  this  compile  to  bytecode  process  which 
makes  it  similar  to  the  Java  Virtual  Machine. 

C.  CURRENT  STATE  OF  THE  ART  ENGINES 

Currently,  there  are  several  different  commercial  game  companies  that 
have  developed  their  own  game  engines.  When  it  comes  to  pushing  the  latest 
technology  to  the  limit,  the  following  game  engines  come  to  mind: 

•  Unreal  Engine™  by  Epic  Games:  Unreal  Tournament  series, 
numerous  3'^'^  party  licensees 

•  Quake  Engine  by  id  Software:  Quake  I/I  I/I  1 1 

•  Doom  3  Engine  by  id  Software:  Doom  3 

•  Source  Engine  by  Valve  Software:  Half  Life  2 


7 


•  CryEngine  by  CryTek;  Far  Cry 

•  Torque  Engine  by  GarageGames 

Generally  speaking,  when  the  term  “state  of  the  art”  is  used,  often  the 
assumption  is  that  this  refers  to  computer  graphics.  Many  games  strive  for  visual 
realism  which  always  pushes  the  latest  video  circuitry  available  on  the  market. 
As  game  developers  quickly  begin  to  make  the  most  use  of  the  available 
hardware,  the  graphics  hardware  manufacturers  are  working  on  the  next 
generation  of  hardware  and  capabilities.  As  developers  push  the  limits  of  what  is 
currently  capable,  manufacturers  are  locked  in  battle  to  produce  the  newest  and 
most  capable  hardware.  Simply  put,  it  creates  a  vicious  cycle. 

Over  the  last  few  years,  computer  graphics  have  been  driving  game 
development  and  have  pushed  the  limits  of  current  graphics  hardware  and 
displays.  The  industry  has  almost  reached  a  point  where  computer  graphics 
technology  is  at  the  point  of  diminishing  returns.  (Tozour02)  The  new  frontier,  or 
perhaps  an  often  neglected  one,  is  Artificial  Intelligence.  If  one  were  to  take  a 
look  at  a  typical  game  development  company  to  see  how  it  is  structured,  one 
could  expect  to  find  a  lot  of  programmers  focused  on  the  game  mechanics;  level 
designers  to  develop  the  levels  and  script  actions;  artists  to  draw  monsters,  other 
characters  and  weapons,  etcetera.  From  looking  at  comments  from  the  Al 
community,  game  reviews  from  the  past  few  years,  and  other  general  comments, 
many  game  developers  have  voiced  the  concern  that  not  much  time  is  spent  on 
Al  for  games.  This  attitude  is  changing  somewhat  as  some  of  the  latest 
generation  of  games  demonstrate  some  rather  sophisticated  Al.  And  while  game 
companies  have  started  to  devote  more  human  talent  and  resources  at  the 
problem  of  Al  in  games,  there  is  still  room  for  improvement.  (Tozour02) 

A  final  thought  on  the  above  mentioned  game  engines  as  it  applies  to  this 
thesis  is  to  design  an  engine  with  the  capability  to  completely  replace  or  augment 
existing  Al  in  these  games.  Game  Engines  like  Unreal  Engine  and  the  Doom  3 
Engine  have  spawned  numerous  web  sites  dedicated  to  inform  those  who  wish 
to  modify  or  ‘mod’  the  game.  Being  able  to  customize  the  existing  Al  or 

completely  replace  it  is  a  valuable  capability. 
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D.  DIFFERENCES  IN  Al  FOCUS 

Up  to  this  point,  much  of  the  focus  of  this  thesis  has  been  placed  on  the 
game  industry.  The  game  industry  continually  pushes  the  limits  of  computer 
hardware  to  ever  increasing  heights,  specifically  in  the  realm  of  computer 
graphics.  The  capabilities  of  the  Graphics  Processing  Unit  (GPU)  have 
increased  at  a  rate  even  higher  than  Moore’s  Law,  an  outside  observer  might 
suggest  that  the  point  of  diminishing  returns  is  rapidly  approaching.  As  the 
industry  approaches  photo  realistic  rendering,  not  much  value  is  added  by 
successive  increases  in  visual  quality.  The  game  may  look  more  visually 
stunning,  but  it  can  still  leave  a  player  wanting.  As  more  powerful  GPUs  are 
introduced  and  can  handle  the  heavy  lifting  of  rendering  the  screen,  the  Central 
Processing  Unit  (CPU)  is  available  to  tackle  other  tasks,  such  as  Al.  With  limited 
resources  in  the  past,  when  it  came  to  Al  capabilities,  the  developers  had  to 
resort  to  tricks  and  shortcuts  to  maximize  the  CPU  cycles  that  were  available  to 
them.  Since  most  of  the  CPU  time  was  used  for  graphics  or  other  functions,  the 
Al  presented  in  the  game  was  often  very  limited. 

In  the  Department  of  Defense,  relatively  little  emphasis  has  been  placed 
on  visual  realism.  Simulations  are  often  used  for  analysis  and  not  necessarily 
used  for  training.  In  the  eyes  of  an  analyst,  the  visualization  while  the  simulation 
is  running  is  generally  not  so  important.  If  the  visual  realism  desired  doesn’t 
drastically  increase  the  total  time  required  to  complete  a  simulation,  then  perhaps 
a  simulation  professional  would  not  object  to  the  improvement  in  graphics.  In 
training  however,  it  is  often  the  case  that  visual  realism  can  improve  the 
participant’s  sense  of  immersion  or  realism.  While  this  is  not  easily  measurable, 
a  common  sense  approach  would  say  that  suspending  disbelief  effectively  draws 
the  participant  into  the  game  or  simulation.  Similarly,  to  enhance  a  participant’s 
level  of  realism  or  immersion,  an  NPC’s  behavior  should  be  believable.  While 
the  game  industry  tends  to  focus  first  on  the  graphics  and  then  the  Al,  the  DoD 
has  worked  toward  more  realism  in  the  arena  of  human  behavior  while  mostly 
ignoring  the  graphics  and  the  potential  improvements  it  brings.  (Scott02) 
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1.  Game  Industry 

In  the  world  of  Al,  there  is  generally  a  difference  in  focus  of  the 
entertainment  and  defense  industries.  Where  the  defense  industry  generally 
looks  to  realism,  the  game  industry  has  focused  on  making  things  look  good 
enough.  In  an  interview  with  Chris  Butcher  from  Bungie,  makers  of  the  popular 
Xbox  games  Halo  and  Halo  2,  he  makes  an  interesting  observation  that  is 
important  (Valdes04).  He  asked  the  interviewer  and  author  of  the  article,  Robert 
Valdes,  if  he  was  familiar  with  the  idea  of  the  “Uncanny  Valley.”  When  the 
interviewer  responded  he  wasn’t  familiar.  Butcher  went  on  to  explain; 

As  characters  become  more  photo-realistic,  you  start  to  believe  in 
them  more  and  more.  With  human  characters,  you  get  to  a  certain 
point  of  realism.  What  happens  is  there  are  characters  that  are  so 
realistic  you  want  to  believe  they  are  actually  human.  Then  you 
notice  their  deficiencies.  They  have  very  plastic  skin  or  very 
wooden  eyes.  All  of  the  sudden  they  just  become  creepy.  They  are 
like  zombie  people,  rather  than  appealing  computer  people.  The 
appeal  of  the  character  rises,  then  drops  dramatically,  then  rises 
again  as  you  approach  photo-realism. 

From  here.  Butcher  comments  that  the  design  goals  for  Halo  and  Halo  2 
were  not  to  be  photorealistic.  But  his  more  pressing  concern  was  the  idea  that 
behavior  in  games  is  approaching  a  similar  ‘uncanny  valley.’  In  combat 
situations,  the  characters  seem  very  lifelike  with  interesting  behavior,  both 
individually  and  in  groups.  However,  a  problem  occurs  when  the  Al  is  faced  with 
situations  they  are  not  programmed  for  and  thus  do  not  have  proper  reactions. 
Often  the  reactions  that  result  make  the  Al  look  unintelligent.  But,  probably  the 
most  relevant  statement  is  the  final  one  from  the  article: 

The  challenge  with  Al  in  games  right  now  is,  'What  are  the 
boundaries  of  Al?  How  do  we  hide  those  boundaries  from  the 
player?  And  how  do  we  go  beyond  them?'  That  is  what  artificial 
intelligence  is  all  about.  It's  about  tricking  the  player  into  believing 
that  there  is  something  intelligent  there. 

This  final  statement  is  one  area  that  seems  problematic,  highlighting  the 
differing  opinions  between  entertainment  and  defense.  In  the  entertainment 
industry,  it  is  sufficient  to  ‘trick’  the  player  into  thinking  there  is  an  intelligent 


10 


player  there.  But  for  DoD  purposes,  it  is  not  sufficient  to  trick  the  trainee.  Many 
of  the  tricks  are  only  applicable  to  limited  situations  and  would  not  likely  work  or 
produce  desirable  results  in  a  more  general  situation. 


2.  Department  of  Defense 

Where  games  generally  have  seemed  to  focus  on  using  scripted 
sequences  and  perfect  knowledge  of  the  game  environment  to  cause  NPCs  to 
act,  the  DoD,  specifically  the  Defense  Advanced  Research  Projects  Agency 
(DARPA),  is  looking  toward  Biologically-Inspired  Cognitive  Architectures  (BICA). 
This  is  the  subject  of  DARPA’s  BICA  program,  which  is  currently  seeking 
proposals.  From  the  DARPA  Program  web  page; 

The  goal  of  the  Biologically-Inspired  Cognitive  Architectures 
Program  via  this  BAA  is  to  develop,  implement  and  evaluate 
psychologically-based  and  neurobiologically-based  theories,  design 
principles,  and  architectures  of  human  cognition.  In  a  subsequent 
phase,  the  program  has  the  ultimate  goal  of  implementing 
computational  models  of  human  cognition  that  could  eventually  be 
used  to  simulate  human  behavior  and  approach  human  cognitive 
performance  in  a  wide  range  of  situations 

DARPA  feels  that,  while  the  traditional  approach  to  machine  intelligence 
pursued  by  the  Al  research  community  has  produced  many  achievements,  it  has 
not  quite  lived  up  to  the  grand  vision  of  “integrated,  versatile,  intelligent  systems.” 
With  this  in  mind,  DARPA  is  placing  its  hopes  in  the  fields  of  neuroscience  and 
cognitive  psychology.  Over  the  last  several  years,  advances  in  equipment  and 
experimentation  have  allowed  a  substantial  improvement  in  understanding  the 
physical  structure  and  function  of  the  human  brain.  Running  in  parallel  to  these 
advances  are  improvements  in  computational  theories  and  architectures  based 
on  modeling  functions  of  human  cognition  like  perception,  memory,  decision 
making  and  even  problem  solving.  Some  of  these  psychologically-based  models 
of  cognition  like  ACT-R  and  SOAR  have  been  able  to  yield  impressive  simulation 
of  human-like  behavior.  By  working  in  the  context  of  human  cognition,  DARPA 
hopes  to  take  a  step  back  and  take  a  fresh  new  look  at  the  design  and 
implementation  of  human  cognition  architectures.  The  goal  is  to  dramatically 
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improve  learning  of  machines  via  these  new  architectures  and  new  theoretical 
work  in  the  areas  of  neuroscience  and  cognitive  psychology.  The  important  thing 
to  note  is  DARPA’s  definition  of  learning.  According  to  the  project  information, 
DARPA  defines  learning  as  “organizing  data  for  creative  and  adaptive  uses.”  In 
this  case,  the  result  of  learning  is  to  be  able  to  effectively  deal  with  new 
situations.  (DARPA05) 


E.  SUMMARY 

The  game  industry  has  only  recently  started  to  put  more  emphasis  on 
improving  the  Al  capabilities  in  the  games  that  are  produced.  In  general,  game 
Al  often  only  exhibits  some  signs  of  intelligence.  If  one  were  to  watch  the  Al 
closely,  depending  on  the  game  and  capabilities  used,  the  Al  only  acts  when  it 
senses  the  player.  Chris  Butcher,  who  developed  the  Al  for  Halo  and  Halo  2, 
comments  that  if  one  were  to  sneak  up  on  the  NPCs  in  the  game  and  then  just  sit 
and  watch,  the  NPCs  will  do  nothing  until  they  sense  the  player.  In  the  real 
world,  it  is  conceivable  to  think  that  the  NPC  should  be  searching  for  his 
opponent,  or  have  some  other  goal  to  achieve.  For  example,  in  a  DoD 
application,  a  NPC  soldier  might  be  digging  a  ditch  or  cleaning  his  weapon.  An 
exception  would  be  in  the  case  of  an  ambush.  The  NPC  would  be  strategically 
placed  to  lie  in  waiting.  Then,  the  NPC  would  come  alive  to  engage  the  player. 
One  could  perceive  this  as  intelligent  behavior  even  though  the  NPC  just  sits 
there.  The  hard  problem  is  what  to  do  once  the  Al  springs  into  action;  how  does 
one  make  it  appear  that  there  is  an  intelligent  being  where  there  really  isn’t  one? 
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III.  COMMON  Al  CAPABILITIES 


A.  INTRODUCTION 

In  this  chapter,  a  look  at  some  of  the  underlying  technologies  found  in 
today’s  successful  game  engines  is  offered.  What  are  the  common  Al 
capabilities  needed  for  use  in  a  game  engine?  These  technologies  will  be  good 
candidates  for  inclusion  into  DeltaSD.  Instead  of  building  Al  from  scratch,  some 
companies  produce  Al  middleware.  A  discussion  of  some  of  the  Al  middleware 
packages  available  today  is  provided.  Finally,  a  look  at  the  relationship  between 
Al  and  animation  is  considered.  The  end  result  should  be  a  basic  understanding 
of  the  common  methods  from  the  field  of  Al  that  are  used  currently. 

B.  GAME  Al  CAPABILITIES  AND  TECHNOLOGIES  IN  USE  TODAY 

Since  the  goal  of  the  DeltaSD  project  is  to  create  an  open  source  gaming 
and  simulation  engine,  it  is  useful  to  look  at  what  Al  capabilities  and  techniques 
are  in  use  in  the  more  successful  game  engines  today.  A  look  at  both  current 
and  past  best  selling  games,  like  DOOM  3,  Half  Life  2  and  Unreal  Tournament 
will  be  a  good  introduction  to  some  of  the  current  technologies  in  use. 

Generally  speaking,  any  game  companies  that  advertise  advanced  Al 
capabilities  are  generally  reluctant  to  make  such  information  or  source  code 
available.  Those  that  have  licenses  to  develop  with  a  particular  game  engine  like 
Unreal  Engine  or  the  Doom  3  Engine  typically  have  access  to  developer 
resources,  and  this  access  comes  at  a  cost.  Despite  this  relative  secrecy  and 
reluctance  to  share  ideas,  there  are  some  common  techniques  that  are  in  use 
today.  Examples  include  the  following:  Pathfinding,  Dead  Reckoning,  State 
Machines,  and  Line  of  Sight.  The  following  subsections  will  discuss  precisely 
these  methods  listed  above. 
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1.  Pathfinding 

As  the  name  indicates,  pathfinding  is  an  algorithm  to  find  a  path  through 
an  environment.  There  are  a  handful  of  algorithms,  but  the  A*  (spoken  like  A- 
star)  search  is  a  method  of  finding  the  cheapest  path  through  a  particular 
environment.  It  is  a  directed  search  algorithm  and  a  heuristic  to  evaluate  the  cost 
of  moving  along  a  particular  path  in  the  search  space.  By  using  this  heuristic 
function,  the  amount  of  processing  time  to  find  a  solution  is  minimized.  In  such  a 
scheme,  if  movement  has  the  equal  cost,  the  cheapest  path  works  out  to  be  the 
shortest  path.  (Russel02) 

In  order  to  take  advantage  of  this  path  searching  capability,  the  game 
environment  must  be  represented  in  such  a  way  that  specifically  defines  where 
movement  is  allowed.  Then,  by  passing  a  start  position  and  a  goal  position,  the 
algorithm  can  search  for  the  path  having  the  least  cost.  Successful  completion  of 
the  A*  search  yields  a  list  of  points  representing  the  path.  (Rabin04) 


2.  Dead  Reckoning 

Dead  reckoning  is  way  of  predicting  an  object’s  future  position  based  on 
its  current  position,  velocity  and  acceleration.  In  essence,  this  is  a  relatively 
simple  form  of  prediction,  since  most  objects  have  movement  that  resembles  a 
straight  line  over  a  short  time.  Some  more  advanced  versions  of  dead  reckoning 
may  be  able  to  give  an  idea  of  how  far  an  object  may  have  moved  since  it  was 
seen  last. 

This  technique  is  often  an  effective  way  to  control  the  difficulty  level  in  a 
first-person  shooter  type  game.  To  decrease  the  difficulty  level  for  the  player,  the 
computer’s  accuracy  at  “leading  the  target”  when  shooting  is  lowered.  Because 
projectiles  can’t  travel  instantaneously,  the  future  position  of  targets  must  be 
predicted.  With  this  prediction,  the  NPC  can  aim  the  weapon  at  the  point  it  has 
predicted  in  order  to  hit  it.  One  possible  way  to  decrease  the  difficulty  level  for 
the  player  could  be  to  make  the  NPC  lead  the  target  too  much,  causing  it  to  miss 
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more  often.  Conversely,  to  make  the  game  more  difficult,  the  prediction  point  will 
be  made  more  accurate.  (Rabin04) 

3.  State  Machines 

Fu  and  Houlette  (Fu02)  claim  that  state  machines  are  the  most  widely 
used  technique  in  game  Al  programming.  Due  to  its  broad  use  in  the  game 
industry,  the  state  machine  can  be  considered  a  cornerstone  of  game  Al.  A  few 
types  of  state  machines  in  use  today  are  discussed  in  the  following  subsections. 

a.  Finite  State  Machine  (FSM) 

As  its  name  implies,  a  finite  state  machine  is  described  by  a  limited 
or  ‘finite’  set  of  states  and  transitions.  An  important  additional  restriction  is  that 
only  one  state  may  be  active  at  any  given  time.  Generally,  a  state  represents  a 
specific  behavior  like  Patrol  or  Attack.  In  a  FSM,  the  state  can  either  actively  poll 
or  passively  listen  for  events  that  will  cause  a  transition  from  its  current  state  to 
one  of  the  other  described  states.  (Rabin04) 


Figure  1 .  A  Finite  State  Machine  Example.  (From:  WikiOS) 
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b.  Stack-Based  State  Machine 

A  stack-based  state  machine  is  similar  to  a  FSM;  however,  it  has 


the  ability  to  remember  past  actions.  The  memory  ability  is  achieved  by  using  a 
common  memory  structure  called  a  stack  to  store  the  past  actions.  The  stack- 
based  state  machine  was  developed  based  on  the  realization  that  it  may  be 
useful  to  be  able  to  return  to  a  previous  state.  Having  a  memory  would  be  useful 
for  a  goal-based  Al.  (Rabin04) 


c.  Fuzzy  State  Machine  (FuSM) 

A  fuzzy  state  machine  is  similar  to  the  FSM;  however  it  uses  the  Al 
technique  of  Fuzzy  logic  to  influence  a  change  in  state.  Where  a  traditional  FSM 
has  a  collection  of  fixed  states  and  transitions  and  a  predicable  outcome,  a  FuSM 
uses  weight  values  to  influence  the  state  transitions.  The  FuSM  is  not  required 
to  be  in  only  one  state  at  a  time,  but  can  be  partially  in  one  or  more  states.  The 
FuSM,  unlike  the  FSM,  is  non-deterministic.  (Rabin04) 

4.  Line  of  Sight 

When  playing  against  other  players,  a  human  player  can  look  at  the 
computer  screen  and  be  able  to  tell  if  his  teammates  and  opponents  are  visible. 
How  does  a  NPC  handle  this  inherent  human  capability?  One  technique  is  called 
Line  of  Sight  (LOS).  In  performing  LOS  calculations,  a  ray  is  drawn  from  the 
observer  to  the  target.  The  computer  knows  where  all  objects  are  and  it  may 
choose  one  or  several  points  on  the  target  to  determine  its  visibility.  In  the  case 
of  a  single  ray,  the  algorithm  might  choose  the  topmost  pixel  and  draw  the  ray 
there.  If  the  LOS  ray  does  not  intersect  some  other  object  before  reaching  the 
target,  it  is  considered  to  be  visible.  Depending  on  what  other  objects  are  in  the 
scene,  the  target  might  be  completely  or  only  partially  obscured.  An  extreme 
example  might  be  that  of  a  leaf  in  the  path  between  the  observer  and  target.  A 
leaf  may  be  pretty  small  and  likely  would  not  obscure  the  target.  However,  if  the 
LOS  ray  were  to  intersect  the  polygon  representing  the  leaf  before  it  reached  the 
target,  the  algorithm  would  consider  the  target  to  be  invisible. 

16 


This  is  not  an  ideal  way  to  determine  visibility.  An  improved  algorithm 
might  choose  several  points  on  the  target  and  try  drawing  multiple  rays.  While 
this  will  likely  reduce  the  chances  of  a  target  being  considered  invisible  because 
of  a  single  leaf  or  small  object,  this  introduces  the  potential  for  many  more 
necessary  calculations,  as  you  must  have  n  rays  for  n  points  on  the  target.  If  you 
have  only  one  observer  and  one  target,  this  might  be  acceptable.  However,  it  is 
common  to  have  multiple  targets,  and  if  there  are  multiple  observers,  that  only 
serves  to  increase  the  number  of  necessary  calculations  to  determine  visibility. 
Because  many  games  only  dedicate  a  certain  amount  of  CPU  processing  time  to 
Al  functionality,  one  can  see  how  that  much  of  it  would  be  quickly  used  up  by 
LOS  calculations  for  multiple  targets  and  observers.  This  would  ultimately  leave 
little  CPU  time  for  other  vital  Al  algorithms  to  function.  (MorganOS) 


5.  Scripting 

Scripting  is  a  way  of  defining  game  data  or  logic  outside  of  the  game’s 
development  language.  In  the  past,  the  game  developers  have  often  written 
scripting  languages  from  scratch.  However,  there  has  been  more  interest  in 
using  languages  such  as  Python  or  Lua  as  opposed  to  developing  one  from 
scratch.  While  the  popularity  of  scripting  languages  has  been  increasing,  the  use 
of  scripting  languages  covers  a  wide  spectrum  from  no  scripting  to  having  the 
entire  game  written  in  script  code.  Table  1  below  illustrates  this  wide  spectrum. 
(Rabin04)  Most  games  can  be  found  in  the  middle  levels  because  the  extreme 
ends  of  this  spectrum  often  increase  risk,  time  and  cost. 
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Scripting  influence  spectrum 

Level  0 

Hard  code  everything  in  the  source  language  (C/C++). 

Level  1 

Data  in  files  specify  stats  and  locations  of  characters/objects. 

Level  2 

Scripted  cutscene  sequences  (noninteractive) 

Level  3 

Lightweight  logic  specified  by  tools  or  scripts,  as  in  a  trigger  system. 

Level  4 

Heavy  logic  in  scripts  that  rely  on  core  functions  written  in  C/C++. 

Level  5 

Everything  coded  in  scripts  -  full  alternative  language  to  C/C++. 

Table  1.  Scripting  Influence  Spectrum.  (From:  Rabin04) 

C.  OPEN-SOURCE  Al  PACKAGES 

One  of  the  goals  of  the  DeltaSD  project  is  to  use  existing  open-source 
software  packages  and  to  incorporate  them  in  the  engine.  As  the  following 
section  will  discuss,  there  are  open-source  projects  that  are  trying  to  define  and 
build  the  basic  Al  framework  necessary  for  game  development.  Specifically, 
there  are  two  open-source  Al  projects  that  will  be  covered:  the  OpenAI  project 
and  Flexible  Embodied  Animat  aRchitecture  or  FEAR.  In  addition  there  are 
Partial  Al  packages.  The  available  partial  Al  packages  provide  only  a  small  part 
of  the  required  Al  in  a  game,  but  that  small  part  is  often  done  extremely  well.  In 
addition,  they  tend  to  have  a  vibrant  support  community.  For  the  interested 
reader  SmithOS  covers  more  details  on  a  few  such  packages. 

Unlike  the  partial  Al  packages  just  mentioned,  the  two  packages  above 
are  what  some  might  call  all  inclusive  Al  packages.  Such  packages  attempt  to 
include  a  wide  number  of  Al  disciplines.  In  addition,  many  such  projects  start  off 
with  a  small  dedicated  developer  community.  The  project  leader  gets  hired  away 
by  a  big  game  company  and  is  forbidden  by  contract  to  work  on  any  side 
projects.  With  the  leader  effectively  removed,  interest  dies  off  and  the  project 
withers  on  the  vine.  Not  all  projects  end  this  way,  but  it  seems  to  be  a  common 
occurrence  (SmithOS). 
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1.  OpenAI 

OpenAI  is  considered  an  all  inclusive  Al  package.  It  was  designed  to  be 
open-ended  framework  and  development  suite  (SmithOS).  In  addition  it  is  set  to 
work  with  multiple  programming  languages  like  JAVA  and  C++.  There  were  also 
some  graphical  user  interface  tools  to  help  out  those  with  less  programming  skill. 
The  lofty  goals  of  the  project  listed  the  following:  “We  hope  to  be  known  as  the 
OpenGL  of  Artificial  Intelligence.”  (OpenAIOS)  In  essence,  the  project  sought  to 
develop  a  specification  for  Al  related  tools. 

The  OpenAI  site  discusses  the  development  of  such  Al  tools  and  modules 

like: 

•  Neural  Networks 

•  Genetic  Algorithms 

•  Finite  State  Machine 

•  Mobile  Agent  System 

Unfortunately,  this  project  is  no  longer  actively  developed.  The  web  site 
shows  posts  ending  back  in  2003  (OpenAIOS).  This  seems  to  be  a  common  fate 
with  many  open  source  efforts  as  those  involved  often  have  other  commitments 
to  attend  to. 

2.  Flexible  Animat  Embodied  aRchitecture  (FEAR) 

FEAR  was  pioneered  by  Alex  J.  Champandard  and  was  designed  to  be  an 
extensible  framework  to  create  Al  agents  in  games.  The  initial  efforts  for  a 
working  sample  focused  on  the  use  of  the  Quake  II  engine;  however  the 
architecture  could  be  used  with  other  programs.  The  FEAR  project  approaches 
the  problem  of  Al  from  a  different  perspective.  The  project  aims  to  have  the 
framework  be  the  basis  for  any  type  of  Al  could  be  modeled.  Most  commercial  Al 
middleware  packages  tend  to  focus  on  one  particular  type  of  Al  functionality. 
The  FEAR  architecture  hopes  to  provide  a  platform  to  build  whatever  Al  tools  are 
necessary  for  a  particular  application.  (SmithOS) 
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One  of  the  pitfalls  of  FEAR  is  that  it  requires  the  program  has  a  fairly 
thorough  working  knowledge  of  Al.  For  the  adventurous  and  interested  parties, 
there  are  several  examples  that  implement  some  of  the  following  Al  techniques: 
Neural  Networks,  path  finding  algorithms,  and  path  planning  algorithms.  Others 
are  available  and  are  only  limited  to  a  programmer’s  knowledge  of  Al  and  how  to 
implement  it  in  software  code. 

Another  area  that  makes  FEAR  extensible  is  the  addition  of  an  XML  based 
language  for  Al  development.  This  can  allow  those  with  little  programming 
knowledge  to  gain  proficiency  with  FEAR.  Though  the  use  of  XML  language 
makes  things  more  flexible,  it  is  not  as  easy  as  a  GUI  like  those  found  in  many 
commercial  packages  or  as  in  OpenAI. 

Since  its  inception  in  2002  by  Alex  Champandard,  he  accomplished  much 
to  improve  the  state  of  Al  in  games  by  striving  toward  a  unified  framework  and 
toolset,  the  project  has  not  seen  further  development  since  2004.  After  being 
hired  by  Rock  Star  Studios  to  work  on  the  Al  for  the  Max  Payne  series  of  games, 
he  had  to  distance  himself  from  this  project  somewhat.  He  did  however  have 
time  to  write  a  book  Al  Game  Development  which  has  some  examples  that  could 
be  used  in  any  games  using  FEAR.  (SmithOS) 


D.  Al  MIDDLEWARE 

One  of  the  newer  ideas  in  Al  software  is  something  called  Al  middleware. 
Al  middleware  is  a  software  service  for  a  game  engine  that  performs  the  Al 
function.  Basically,  the  game  developer  can  buy  Al  middleware  instead  of 
building  up  an  Al  library  from  scratch,  or  more  commonly  referred  to  as  “rolling 
your  own.”  Some  reasons  for  using  Al  middleware  in  game  development  might 
be:  lack  of  developer  experience  with  Al,  lack  of  expertise  to  design  and 
implement  Al  algorithms,  tight  project  schedules  that  don’t  permit  the  in  house 
developers  enough  time  to  develop  the  Al  to  a  desired  level,  or  the  Al 
middleware  might  already  contain  the  level  of  Al  functionality  desired  for  the 
project.  (DybsandOS) 
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While  the  idea  of  simply  purchasing  the  Al  functionality  needed  for  a  game 
or  simulation  seems  enticing,  there  are  some  potential  pitfalls  to  consider.  First, 
from  a  strictly  programmer  perspective,  is  the  idea  of  the  Al  as  “not  invented 
here.”  A  game  developer  often  makes  claims  on  the  technologies  implemented 
in  a  game  or  game  engine,  so  a  good  Al  in  a  game  is  a  source  of  developer 
pride.  Second,  and  closely  related  to  the  “not  invented  here”  syndrome,  is  the 
idea  that  the  developer  does  not  have  complete  control  over  the  software. 
Thirdly,  the  idea  that  there  is  a  potential  performance  hit  imposed  by  accessing 
the  Al  middleware  library.  This  may  also  create  anxiety  because  the  developer 
cannot  necessarily  access  the  software  code  to  optimize  it  for  a  particular 
application.  Another  concern  is  that  the  middleware  may  not  provide  all  of  the 
desired  functionality  for  a  given  project.  This  would  likely  mean  that  a  developer 
might  spend  much  more  time  trying  to  add  the  functionality  or  looking  for  other 
middleware  that  more  closely  supports  the  desired  capability.  And  finally,  it  is 
quite  possible  that  the  learning  curve  to  implement  the  Al  middleware  into  the 
game  engine  is  too  steep.  This  may  end  up  meaning  that  the  cost  of  the 
middleware  combined  with  the  difficulty  in  implementing  the  library  is  more  that 
the  time  involved  in  writing  the  Al  functionality  from  scratch. 

An  article  in  Gamasutra  by  Eric  Dybsand  takes  a  closer  look  at  four  Al 
middleware  products  that  offer  character  behavior.  To  assess  the  products,  the 
following  three  questions  are  asked: 

•  Question  1 ;  What  does  the  product  do  for  the  developer? 

•  Question  2:  What  are  the  main  features? 

•  Question  3:  How  is  the  product  implemented  in  a  game? 

The  following  are  the  names  of  the  four  Al  middleware  packages  that  were 
investigated  in  the  article.  There  are  other  Al  middleware  products,  but  the 
author  chose  to  focus  on  ones  that  offer  character  behavior. 

•  Al. implant,  by  BioGraphic  Technologies  of  Montreal,  Canada 

•  DirectIA,  by  Mathematiques  Appliquees  S.A.  of  Paris,  France 

•  RenderWare  Al,  by  Criterion  Software  Inc.  of  Austin,  Texas 

•  SimBionic,  by  Slotter  Henke  of  San  Mateo,  California 
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The  article  is  actually  split  up  into  several  individual  articles;  one  dedicated 
to  each  of  the  four  Al  middleware  offerings.  Figure  2  below  shows  the  basic 
relationship  of  character  behavior  to  the  game  engine  and  to  the  middleware, 
while  Table  2  on  the  following  page  summarizes  the  findings. 
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Figure  2.  Al  Middleware  Block  Diagram  (From:  DybsandOS) 
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E.  Al  AND  ANIMATION 

This  section  will  look  at  the  relationship  between  Al  and  animation. 
Specifically  it  will  address  the  role  of  scripting  languages  in  controlling  animation. 
A  brief  look  at  how  the  UnrealEngine  handles  animation  is  covered.  Finally,  a 
look  at  how  animation  control  is  implemented  currently  in  DeltaSD  is  provided. 

When  one  thinks  of  Al,  one  might  not  think  of  animation  as  being  related. 
The  converse  is  also  true:  thinking  of  animation  doesn’t  necessarily  lead  one  to 
think  of  Al.  However,  upon  closer  consideration,  the  two  are  related  and  it  is 
important  to  be  mindful  of  this  fact.  Recalling  the  definition  of  a  NPC  mentioned 
in  the  previous  chapter,  there  are  two  logical  parts  to  a  NPC:  the  controller  and 
the  body.  It  is  here  where  the  idea  of  the  relationship  between  Al  and  animation 
begins  to  make  sense.  Simply  put,  the  controller  is  the  Al  portion  of  the  NPC  and 
the  body  is  the  “physical”  representation  of  the  NPC.  It  is  the  body  that  gets 
animated.  So,  as  the  controller  is  sensing  information  about  the  environment  and 
making  decisions,  the  net  result  is  some  form  of  action  by  the  body.  Part  of  the 
controller’s  function  is  to  decide  which  animation  to  play  based  on  the  current 
state. 


1.  Animation  in  Unreal 

First  a  look  at  how  animation  is  controlled  in  Unreal  Tournament  is 
needed.  Unreal  Engine  has  a  skeletal  animation  system.  There  are  other  types 
of  animation  systems,  like  keyframe  animation.  The  skeletal  animation  system 
has  become  the  common  technology  used  today  in  games.  Unreal  Engine  has  a 
set  of  basic  animations  which  can  be  called  depending  on  the  state  of  the  Al.  If 
the  NPC  is  running,  it  will  play  a  running  animation.  If  the  NPC  is  turning  to  face 
an  opponent,  it  has  a  turning  animation.  In  addition,  to  transition  between 
animations  there  is  a  way  to  play  blend  animations  together.  One  of  the  benefits 
of  the  skeletal  animation  system  is  that  different  animations  can  be  combined  on 
the  fly.  This  reduces  the  number  of  animations  that  need  to  be  developed. 
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To  get  an  idea  of  how  Unreal  works,  a  look  at  some  code  from  one  of  the 
Unreal  hot  classes  is  useful. 


state  Flee 
{ 

ignores  SeePlayer,  TakeDamage,  HearNoise,  Falling,  Bump; 

Begin : 

Destination  =  Location  +  10*CollisionRadius*Normal (Location- 
Target  .  Location)  ; 

TweenToRunning  (0.1) ; 

PlayRunning ( ) ; 

MoveTo  (Destination) ; 

Acceleration  =  vect  ( 0, 0 , 0 ) ; 

GotoStateLogged ( ' Startup ' ) ; 

Figure  3.  Code  Snippet  from  NPSbot-Flee  from  MV4025  Course  Materials 

The  above  code  represents  one  of  the  states  for  the  NPC  in  Unreal  called 
Flee.  As  the  name  suggests,  when  a  NPC  transitions  to  the  Flee  state  it  will 
execute  the  code  defined  in  the  UnrealScript  code.  In  this  case,  it  calls  a  function 
called  TweenToRunning  to  transition  between  the  current  animation  and  the 
running  animation.  So,  most  likely  the  bot  is  either  standing  around  idle  or 
walking.  The  TweenToRunning  function  allows  the  animation  system  to  attempt 
a  smooth  transition  from  idle  to  run  or  walk  to  run.  Now  that  the  animations  are 
playing,  the  script  calls  the  MoveTo  function.  The  MoveTo  function  takes  an 
argument  that  represents  the  desired  location  for  the  NPC  to  move  to.  The  script 
roughly  calls  for  the  NPC  to  move  away  from  the  enemy  about  10  times  the 
distance  between  itself  and  the  enemy.  At  that  point,  the  script  instructs  the  NPC 
to  alter  its  state.  The  end  result  of  the  script  would  be  that  the  NPC  runs  away 
from  the  enemy.  The  state,  more  or  less,  determines  what  animation  or 
animations  are  played. 

2.  Animation  in  DeltaSD 

In  the  DeltaSD  project,  animation  is  handled  with  two  products:  Character 
Animation  Library  (Cal3D)  and  ReplicantBody.  Since  the  underlying  graphical 
capability  of  DeltaSD  is  OpenSceneGraph  (OSG),  the  project  had  to  pick  existing 
open  source  software  packages  that  worked  with  OSG.  CalSd  was  the  package 
chosen.  It  is  a  skeletal  based  3D  character  animation  library.  It  consists  of  two 

25 


parts:  the  C++  library  and  an  exporter.  The  exporter  is  used  to  take  3D  character 
models  built  in  popular  modeling  packages,  like  Discreet’s  3D  Studio  Max  or 
Alias  Maya,  and  convert  them  into  files  in  a  format  understood  by  Cal3d. 
(Cal3d05) 

In  addition,  the  ReplicantBody  software  was  chosen.  ReplicantBody 
allows  movement  based  on  characters  feet,  ground  following  (clamping  the 
character  to  ground)  and  the  ability  to  blend  animations  together.  (RBodyOS)  In 
theory,  the  ReplicantBody  software  would  allow  the  playing  of  two  completely 
separate  animations  like  walking  and  waving.  Because  it  is  based  on  a  skeleton, 
the  bones  are  grouped  and  therefore  influence  each  other.  So,  as  long  as  the 
walking  and  waving  animations  are  set  up  properly,  the  two  should  be  able  to  be 
played  at  the  same  time.  This  scenario  would  require  that  the  bones  used  in  the 
hand  wave  animation  are  not  animated  in  the  walking  animation. 

ReplicantBody  is  basically  an  enhancement  to  the  capabilities  to  Cal3d. 
By  setting  up  the  .rbody  file  one  can  define  the  animations  that  the  character  can 
perform.  The  rbody  file  is  a  configuration  file,  allowing  one  to  link  the  skeleton  file 
to  the  materials  and  meshes  that  make  up  the  character.  On  the  following  page 
located  in  Figure  4  is  a  snippet  of  code  from  the  Marine. rbody  file  found  in  the 
Delta3D  project.  Using  a  skeleton,  meshes  and  basic  animations  modeled  in 
3dsmax  a  Marine  character  was  created  for  use  in  the  demo  applications 
available  for  Delta3D. 

The  code  shown  on  the  following  page  sets  up  a  character  instance.  The 
first  thing  set  is  the  path  to  where  the  supporting  files  are,  like  the  skeleton  file.  It 
also  defines  a  default  action,  or  animation,  to  be  played.  In  addition  the  scale  of 
the  character  is  set  as  well  as  an  offset  for  the  feet.  As  mentioned  earlier, 
ReplicantBody  offers  movement  based  on  a  characters  feet.  Here  one  sees  that 
the  contact  bones  are  what  represent  the  feet,  and  that  both  a  left  and  right  foot 
are  defined.  A  direction  bone  is  also  identified.  This  bone  allows  one  to  get  the 
direction  that  the  model  is  facing;  in  this  model,  it  is  the  head  bone  that  is  used 
for  direction.  Next  the  animations  are  defined.  In  this  sample  code,  two  of 
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several  animations  are  presented.  In  this  case  there’s  an  animation  for  stand 
and  for  walk.  Each  animation  has  some  parameters  assigned  to  it  like;  a  name, 
the  filename  of  the  Cal3d  animation  file,  an  action  name,  an  action  weight,  a 
speed  and  a  Boolean  value  to  determine  whether  or  not  the  animation  will  loop. 


#  ReplicantBody  vO.l 

path  " . /marine" 
skeleton  "marine_skel . csf " 
default_act  "ACT_STAND" 
scale  0.026 

foot_offset  3.0  //  Before  scaling 

//  Bones  used  when  calculating  character  speed 
ContactBones  { 

bone_name  "BipOl  L  Foot" 
bone_name  "BipOl  R  Foot" 

} 

//  Bones  from  which  you  can  get  the  direction 
DirectionBones  { 

head_bone  "BipOl  Head" 

} 

Animation  { 

name  "stand" 

filename  "marine_stand. caf " 
act_name  "ACT_STAND" 
act_weight  1 . 0 
speed  0 . 0 
is_looped  1 

} 

Animation  { 

name  "walk" 

filename  "marine_walk . caf " 
act_name  "ACT_WALK" 
act_weight  1 . 0 
speed  2 . 0 
is_looped  1 

} 


Figure  4.  Code  Snippet  from  marine. rbody  from  Delta3D/data/marine/ 


F.  SUMMARY 

In  this  chapter,  some  of  the  common  types  of  Al  technologies  in  use  today 
were  presented  in  brief.  In  addition,  the  topic  of  Open  Source  packages 
available  to  day  was  addressed  with  a  comparison  of  two  specific  packages.  Al 
Middleware  is  another  possibility  and  was  looked  at,  specifically  discussing  four 
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separate  packages  available  on  the  market  today.  And  finally,  a  look  at  how  Al 
and  animation  are  important  in  and  of  themselves,  but  that  they  are 
interconnected  as  Al  will  drive  the  appropriate  animation  to  be  displayed. 
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IV.  SCRIPTING  LANGUAGES 


A.  INTRODUCTION 

This  chapter  will  look  at  some  of  the  common  scripting  languages  in  use 
today.  Then  it  will  focus  on  some  advantages  of  scripting  languages  and  how 
this  relates  to  Al.  Finally,  the  application  of  scripting  languages  to  a  game  engine 
is  looked  at.  Specifically,  a  look  at  how  DeltaSD  incorporated  the  Python 
language  in  DeltaSD  and  some  example  Python  scripts  will  be  provided. 


B.  PROGRAMMING  LANGUAGE  BACKGROUND 

Before  getting  into  the  topic  of  scripting  languages,  a  brief  background  of 
programming  languages  in  general  may  be  helpful.  A  discussion  of  low  level, 
high  level  and  very  high  level  languages  follows.  In  addition,  a  look  at  the 
difference  between  interpreted  versus  compiled  languages  is  covered.  Finally,  a 
comparison  of  statically  versus  dynamically  typed  languages  is  presented. 

In  the  early  days  of  computing,  a  programmer  required  detailed  knowledge 
about  the  internal  workings  of  the  specific  computer  they  wished  to  program.  In 
essence,  the  programmer  was  required  to  know  machine  language  and  the 
programs  were  written  in  this  low  level  language.  Next  came  assembly 
language,  which  is  one  step  higher  than  machine  language.  It  is  considered  one 
step  higher  than  machine  language  because  the  native  machine  language 
commands  are  replaced  by  mnemonic  commands  on  a  one-to-one  basis.  The 
mnemonic  command  names  are  more  human  friendly,  making  it  easier  to 
program.  By  running  the  assembly  language  through  an  assembler  program,  the 
mnemonic  commands  are  converted  into  the  corresponding  machine  language 
commands.  The  mnemonics  also  allow  symbolic  addresses  for  data  items  and 
the  assembler  program  assigns  them  to  machine  addresses  and  ensures  that 
there  is  no  overlap  or  overwrites.  Early  on,  assembly  was  used  often  for  games 
found  on  platforms  like  MS-DOS  or  Apple;  however,  as  games  grew  in  size, 
programmers  found  out  rather  quickly  that  assembly  language  did  not  scale  well. 
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Put  another  way,  assembly  language  became  more  difficult  to  maintain  and  was 
not  portable.  The  end  result  is  that  programming  in  assembly  language  is 
avoided  except  in  cases  were  optimal  performance  is  required,  like  in  a  device 
driver.  (Gutschmidt04) 

Next  there  came  high-level  languages.  Some  common  examples  of  high- 
level  languages  are  BASIC,  COBOL,  FORTRAN  and  C/C++.  These  high-level 
languages  are  closer  in  resemblance  to  common  language  and  therefore  easier 
to  use.  Another  benefit  of  high-level  languages  is  that  a  programmer  need  not 
have  a  detailed  knowledge  of  the  low  level  internal  workings  of  a  computer  to 
program  these  instructions.  Writing  one  line  of  high-level  language  code,  an 
instruction,  will  typically  translate  to  several  machine  code  instructions  that  can 
be  compiled  or  interpreted  into  machine  code.  (Gutschmidt04) 

Another  important  distinction  among  computer  programming  languages  is 
the  idea  of  an  interpreted  versus  a  compiled  language.  An  interpreted  language 
will  translate  a  programmer’s  code  step-by-step  at  runtime.  A  compiled  language 
must  translate  the  programmer’s  code  before  it  can  be  run.  This  is  the  compiling 
process.  First  the  code  is  run  through  a  compiler  program  to  generate  object 
code.  Then,  the  object  code  is  linked  to  any  needed  libraries  by  a  linker  program 
to  produce  a  final  executable.  See  Figure  5  below.  (Gutschmidt04) 


Figure  5. 


Compiling  Process  taken  from  Game  Programming 
with  Python,  Lua,  and  Ruby  (From:  Gutschmidt04) 
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Finally,  programming  languages  can  be  statically  or  dynamically  typed.  In 
a  programming  language,  a  type  system  defines  the  way  in  which  data  is 
organized.  Statically  typed  languages  need  predefined  types  for  any  data  to  be 
used  in  the  program.  Some  examples  of  data  types  are  strings,  integers,  float,  or 
vectors.  To  perform  an  addition  operation  on  two  integers,  one  might  declare 
three  variables:  X,  Y  and  Z.  If  the  equation  that  defines  the  addition  operation 
were  Z  =  X  +  Y,  all  three  variables  must  be  explicitly  defined  as  integers.  It  would 
not  make  sense  to  define  the  data  type  for  the  result  (Z)  to  be  a  string  when  the 
code  is  trying  to  add  two  integers  (X  and  Y).  On  the  other  hand,  dynamically 
typed  languages  handle  the  data  types  automatically.  Using  the  same  addition 
example  Z  =  X  +  Y,  if  a  programmer  set  X  =  1  and  Y  =  2  the  language  knows  that 
1  and  2  are  integers.  Furthermore,  it  could  gracefully  handle  the  following  similar 
case.  Say  X  =  1  (an  integer)  and  Y  =  2.5  (a  decimal  or  float  value).  The 
language  is  smart  enough  to  make  X  =  1.0  (a  float)  so  that  it  can  add  X  and  Y 
and  yield  the  result  of  2.5.  The  variable  Z  automatically  becomes  a  float.  This 
automatic  type  capability  is  quite  powerful,  but  it  does  cause  some  potential 
performance  loss.  Computer  hardware  of  today  is  very  fast,  so  this  performance 
hit  may  be  negligible;  however,  it  is  important  to  be  aware  of  this.  (Gutschmidt04) 


C.  COMMON  LANGUAGES  IN  USE  TODAY 

As  mentioned  in  Chapter  1  of  this  thesis,  Berger02  defines  a  scripting 
language  as  “any  programming  language  that  is  created  to  simplify  any  complex 
task  for  a  particular  program.”  A  look  at  the  major  game  engines  available  today, 
most,  if  not  all,  have  an  associated  scripting  language.  While  many  game 
companies  have  created  languages  from  scratch,  some  are  using  preexisting 
languages  to  serve  this  function.  Languages  like  Python  and  Lua  are  examples 
of  preexisting  languages  while  UnrealScript  is  an  example  of  one  that  was 
created  from  the  ground  up  specifically  for  use  in  a  game  engine.  There  are 
many  scripting  languages  available  today;  however,  for  the  purposes  of 
discussion  only  three  will  be  covered:  Python,  Lua  and  UnrealScript. 
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Before  discussing  the  individual  languages,  it  is  worthwhile  to  note  that, 
even  today,  a  universally  accepted  definition  of  a  pure  scripting  language  still 
does  not  exist.  Despite  this,  if  one  chose  any  scripting  language  today,  the 
following  features  are  commonly  found: 

•  Interpreted  language 

•  Simple  syntax 

•  No  pointers 

•  Memory  allocation  handled  by  the  language 

•  Garbage  collection  handled  by  the  language 

•  Interactive:  can  provide  feedback  to  the  programmer  while  running 

•  Code  stored  as  plain  text 

Several  other  common  features  exist,  but  the  above  list  is  a  fair  representation  of 
scripting  languages.  (Gutschmidt04) 

1.  Python 

One  of  the  most  popular  computer  programming  languages  today  is  the 
Python  scripting  language.  Developed  by  Guido  van  Rossum  at  the  National 
Institute  for  Mathematics  and  Computer  Science  in  the  Netherlands,  Python  is 
copyrighted  but  the  source  code  is  freely  available.  For  the  trivia  minded,  the 
language  actually  derived  its  name  from  the  TV  series  Monty  Python’s  Flying 
Circus.  It  is  a  high-level,  interpreted  language  and  is  often  considered  interactive 
and  an  object-oriented  scripting  language.  (Gutschmidt04) 

Some  features  that  make  it  quite  attractive  are  the  following: 

•  Broad  standard  library  widely  available  on  many  platforms  (UNIX, 
Windows  and  Macintosh) 

•  Supports  an  interactive  mode  allowing  interactive  testing 

•  High  portability  (interpreters  available  for  many  major  platforms) 

•  Support  for  Object  Oriented  Programming  (OOP),  specifically  with 
things  like  multiple  inheritance,  classes,  namespaces,  etc. 

•  Easy  integration  with  C,  C++,  Java  and  other  languages 
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2.  Lua 

Another  popular  scripting  language  is  Lua  (pronounced  LOO-ah).  It  is  a 
lightweight  language  that  was  originally  designed  to  extend  applications,  but  it 
can  be  and  often  is  used  as  a  stand-alone  language.  Like  Python,  it  is 
dynamically  typed  and  has  features  like  automatic  memory  management  and 
garbage  collection.  It  is  features  like  this  that  make  Lua  a  great  language  for 
rapid  prototyping.  Lua  was  developed  by  a  team  at  Tecgraf,  the  Computer 
Graphics  Technology  Group  at  Pontifical  Catholic  University  in  Rio  de  Janeiro, 
Brazil.  Like  Python  it  is  freely  available,  but  Tecgraf  retains  the  copyright. 
(Gutschmidt04) 

Some  features  that  make  this  attractive  are  the  following: 

•  Simple  syntax 

•  Support  for  OOP,  specifically  classes  and  inheritance 

•  Ability  to  extend  the  language  in  unconventional  ways 

•  Programs  compile  to  byte-code  and  then  interpreted  similar  to  the 

JAVA  virtual  machine 

3.  UnrealScript 

Following  the  “build  your  own”  approach.  Epic  Games  spent  considerable 
effort  in  making  UnrealScript.  UnrealScript  is  very  similar  in  syntax  to  Java  or 
C++  so  it  is  should  be  somewhat  familiar  to  programmers  with  C/C++  experience. 
Unlike  Python  and  Lua,  UnrealScript  is  a  statically  typed  language.  Variables  in 
UnrealScript  must  be  defined  specifically  and  cannot  change  type  once  defined. 
Though  the  dynamic  typing  of  languages  like  Python  or  Lua  is  certainly 
convenient,  UnrealScript,  with  its  static  typing,  has  been  used  quite  successfully 
to  modify  the  Unreal  Al  capabilities. 
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D.  APPLICATION  TO  A  GAME  ENGINE 

The  following  section  will  look  at  two  examples  of  how  a  scripting 
language  is  implemented.  Specifically,  a  look  at  some  sample  code  and 
explanations  of  what  the  code  does  will  be  provided  for  UnrealScript  in 
UnrealEngine  and  Python  in  DeltaSD. 

1.  UnrealScript  in  Unreal  Engine 

Since  the  model  in  Unreal  is  that  of  a  State  Machine,  the  code  in  Figure  6 
(following  page)  represents  a  state  called  “Flee.”  When  a  NPC  takes  damage 
from  a  bullet,  it  wouldn’t  make  a  lot  of  sense  for  the  NPC  to  just  stand  there  and 
wait  for  another  bullet  to  come  along.  A  player  observing  this  would  most  likely 
consider  the  Al  to  be  unintelligent.  What  is  more  believable  is  having  the  NPC 
running  away  in  response  to  taking  a  bullet.  In  this  case,  the  Flee  state 
accomplishes  this.  In  this  code,  some  functions  are  being  deliberately  ignored. 
In  addition,  TakeDamage  is  a  function  that  already  exists  for  the  developer,  but 
TakeDamage  was  rewritten  to  transition  to  the  Flee  state.  Having  functions  with 
the  same  names  is  similar  to  the  idea  of  overloading  a  function  in  C++.  Again, 
such  capability  should  feel  quite  familiar  to  programmers  with  C++  experience. 

UnrealScript  makes  modifying  the  Al  of  NPCs  in  the  Unreal  Engine  fairly 
easy.  The  following  is  a  brief  sample  of  UnrealScript  code  representing  the  Flee 
state  mentioned  in  the  paragraphs  above: 


state  Flee 
{ 

ignores  SeePlayer,  TakeDamage,  HearNoise,  Falling,  Bump; 

Begin : 

Destination  =  Location  +  10*CollisionRadius*Normal (Location- 
Target  .  Location  )  ; 

TweenToRunning (0.1) ; 

PlayRunning ( ) ; 

MoveTo (Destination) ; 

Acceleration  =  vect  ( 0 , 0 , 0 ) ; 

GotoStateLogged ( ' Startup ' )  ; 


Figure  6.  Code  Snippet  from  NPSbot-Flee  from  MV4025  Course  Materials 
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2.  Python  in  DeltaSD 

Selecting  a  scripting  language  that  suits  one’s  purposes  is  not  an  easy 
task.  In  the  pursuit  of  adding  scripting  ability,  the  DeltaSD  project  looked  at  two 
main  language  options:  Python  and  Lua.  After  much  discussion  and  weighing 
the  pros  and  cons  of  each  language,  Python  was  chosen  as  the  language  to  use 
for  scripting  in  DeltaSD.  Though  the  selection  of  Python  seems  to  be  a  simple 
choice,  it  was  not  trivial  to  embed  the  capability  into  the  DeltaSD  engine.  The 
following  is  a  simple  Python  script  that  will  create  a  small  DeltaSD  application. 

a.  Sample  Python  Script 

The  following  code,  shown  as  Figure  7,  is  a  relatively  simple  script 
that  generates  a  small  DeltaSD  application.  A  step  by  step  discussion  of  what 
this  script  represents  is  necessary.  Following  that  will  be  a  discussion  of  the 
pieces  involved  to  make  this  script  perform  something  useful. 


from  dtCore  import  * 
from  dtABC  import  * 

from  math  import  * 
from  time  import  * 

def  radians (v) ; 

return  v  *  pi/180 

class  TestPythonApplication (Application) : 
def  Config  (self )  : 

Application .Config(self) 

SetDataFilePathList ('../.. /data ' ) ; 

self.helo  =  Object  ( 'UH-IN' ) 

self . helo . LoadFile ( 'UH-IN/UH-IN. ive ' ) 

self . Get Scene ( ) . AddDrawable ( self . helo) 

self  .  transform  =  TransformO 

self. angle  =  0.0 

def  PreFrame (self ,  deltaFrameTime) : 

self . transform. Set (40*cos (radians (self .angle) ) , 

100  +  40*sin (radians (self .angle) ) , 

0,  self. angle,  0,  -45) 
self.helo. SetTransform (self. transform) 
self. angle  +=  45*deltaFrameTime 

testPythonApp  =  TestPythonApplication (' config . 

xml '  ) 

testPythonApp . Config ( ) 
testPythonApp . Run ( ) 

Figure  7.  Code  Snippet  from  testpython.py 


S5 


The  script  starts  of  by  importing  functions  available  in  other 
packages.  Notice  the  asterisk  (“*”)  on  the  first  line.  The  asterisk  tells  the 
interpreter  to  load  all  functions  that  are  in  the  package  dtCore,  the  most  basic 
part  of  the  DeltaSD  engine.  Simply  put,  these  functions  comprise  the  core  of 
DeltaSD  functionality.  Next  it  pulls  in  all  the  functions  in  dtABC  package.  The 
ABC  in  dtABC  stands  for  Application  Base  Class.  The  dtABC  class  in  DeltaSD 
contains  the  basic  application  functionality.  Similarly,  it  imports  all  the  functions 
available  in  the  math  and  time  packages.  Failure  to  include  the  math  package  in 
Python  would  cause  errors  to  occur  the  first  time  a  function  such  as  the  cosine 
(“cos”)  was  called  in  the  script.  Since  it  is  quite  common  to  call  upon  other 
packages  in  Python,  it  is  important  to  make  sure  that  all  the  necessary  packages 
are  linked.  This  is  done  via  the  import  command. 

Next  a  simple  function  called  radians  is  defined.  This  function  is 
used  in  the  PreFrame  section  of  code.  It  is  simply  a  convenience  for  the 
programmer,  as  the  conversion  of  degrees  to  radians  occurs  several  times  in  this 
short  script  file.  Rather  than  repeatedly  type  the  degrees  to  radians  conversion 
throughout  the  code,  the  function  simplifies  the  script  and  makes  it  more 
readable. 

The  next  section  of  code  is  a  class  definition  for  the  file.  In  this 
case,  a  class  is  created  that  inherits  from  the  Application  class  in  DeltaSD.  In  this 
TestPythonApplication  class,  we  have  two  methods  or  functions.  The  first  is 
Config,  which  sets  up  the  configuration  of  the  small  application.  Because  it 
inherits  from  the  Application  class  in  dtABC,  it  can  call  the  Config  method  from  its 
parent  class  (similar  to  the  super  operator  in  C++).  The  local  Config  method  also 
tells  the  application  where  the  data  files  are  located.  Next  it  creates  a  Python 
object.  This  object  loads  a  model  from  the  ones  available  in  DeltaSD  as  part  of 
the  download.  In  this  particular  example,  the  test  application  is  using  a  model  of 
a  UFI-1N  helicopter.  The  AddDrawable()  method  is  called  to  add  the  object  to  the 
scene.  Finally,  it  declares  a  transform  which  allows  the  model  to  be  manipulated 
in  the  scene. 
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The  next  block  of  code  overloads  the  function  PreFrame.  In  this 
case,  the  PreFrame  function  contains  some  code  to  manipulate  the  transform  in 
the  scene.  The  end  result  is  a  helicopter  that  flies  around  in  a  tight  circle.  A 
static  screen  shot  is  presented  on  the  next  page  in  Figure  8. 

The  final  three  lines  of  code  form  the  basic  script.  The  first  line 
names  a  variable  that  creates  an  instance  of  the  TestPythonApplication  class 
defined  in  the  file.  Next  it  calls  the  Config  function  which  configures  the 
application  and  builds  the  basic  scene  by  loading  the  model  and  setting  the 
transform.  Finally  the  Run()  command  is  called.  This  starts  Python  running  and 
ultimately  causes  the  application  to  be  generated  and  displayed  on  screen.  The 
end  result  is  the  helicopter  flying  around  in  a  tight  circle  within  the  application 
window.  As  mentioned  above,  the  resulting  application  is  shown  in  Figure  8. 


Figure  8.  Resulting  Application  from  Python  Script 

b.  Integrating  Python 

Although  this  is  a  fairly  simple  script  file,  there  is  a  lot  going  on 
behind  the  scenes  to  make  this  script  work.  This  section  will  present  a 
background  on  what  supporting  technologies  are  required  to  link  the  Python 
scripting  language  to  the  underlying  DeltaSD  C++  engine  code. 

As  mentioned  earlier,  integrating  the  Python  language  into  DeltaSD 

is  not  trivial.  It  is  not  as  if  one  can  simply  install  Python  and  then  link  to  it  directly 

from  DeltaSD.  To  facilitate  this  linking  requires  a  C++  library  called 
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Boost. Python.  The  primary  goal  of  Boost. Python  is  to  expose  C++  classes  and 
functions  to  Python,  which  ultimately  allows  direct  manipulation  of  C++  objects  (in 
this  case,  DeltaSD  objects)  from  Python.  Through  the  Boost. Python  libraries, 
C++  code  called  a  wrapping  can  be  created.  In  most  cases  it  turns  out  to  be  a 
one  for  one  mapping  of  functions  and  methods  from  C++  to  Python.  In  DeltaSD, 
the  wrappings  are  called  Python  bindings.  For  all  the  major  pieces  of  DeltaSD 
that  will  be  exposed  to  Python,  a  Python  bindings  file  must  be  created.  On  the 
following  page  is  a  snippet  from  the  Python  bindings  file  for  the  DeltaSD 
character  class,  dtChar  (see  Figure  9). 


.def ( "GetVelocity" ,  SCharacter: : GetVelocity ) 

.  def ( "ExecuteAction" ,  SCharacter ; : ExecuteAction,  EA_overloads ( ) ) 
.def ( "ExecuteActionWithSpeed" ,  SCharacter; : ExecuteActionWithSpeed, 
EAWS  overloads () ) 


Figure  9.  Sample  Python  Bindings 


!  -k  -k 

*  Returns  the  current  walk/run  velocity  of  this  character. 

k 

*  @return  the  current  walk/run  velocity 
*/ 

float  GetVelocity ( )  const; 

!  k  k 

*  Executes  a  character  action. 

■k 

*  @param  action  the  name  of  the  action  to  execute 

*  @param  priority  whether  or  not  the  action  is  high-priority 

*  @param  force  whether  or  not  to  force  the  action 

*/ 

void  ExecuteAction ( std: : string  name, 

bool  priority  =  true, 
bool  force  =  false) ; 

!  k  k 

*  Executes  a  character  action  with  a  speed  parameter. 

k 

*  @param  name  the  name  of  the  action  to  execute 

*  @param  speed  the  speed  at  which  to  execute  the  action 

*  @param  priority  whether  or  not  the  action  is  high-priority 

*  @param  force  whether  or  not  to  force  the  action 

*/ 

void  ExecuteActionWithSpeed ( std :: string  name, 

double  speed, 

bool  priority  =  true, 

bool  force  =  false) ; 

Figure  10.  Code  Snippet  from  character.h 
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In  Figure  10  above,  the  GetVelocity(),  ExecuteAction()  and 
ExecuteActionWithSpeedO  functions  are  shown.  These  lines  are  a  small  subset 
of  the  C++  header  file,  character.h.  Looking  at  Figures  9  and  10  together,  one 
can  now  see  that  the  Python  function  names  are  the  same  as  the  function  names 
in  the  character.h  file. 

Not  immediately  apparent  is  what  EA_overloads()  and 
EAWS_overloads  represent  in  the  above  code.  The  purpose  of  the  syntax  above 
is  to  let  Python  know  how  many  arguments  to  expect  for  the  ExecuteAction() 
function.  In  the  case  of  ExecuteAction(),  a  minimum  of  one  argument  is  required 
and  a  maximum  of  three  is  allowed.  At  a  minimum,  this  function  requires  the 
input  of  a  text  string  which  represents  the  name  of  the  action  to  execute.  In 
addition  it  is  expecting  two  Boolean  values.  If  the  code  passes  only  one 
argument,  the  two  Boolean  values  are  assigned  their  default  values  as 
designated  in  the  original  C++  code.  Similarly,  the  second  function  requires  a 
minimum  of  two  arguments  and  a  maximum  of  four.  Failing  to  present  the 
minimum  arguments  will  result  in  an  error  since  there  are  no  default  values  for 
the  name  of  the  action  or  its  speed.  For  the  interested  reader,  the  entire  file  will 
be  available  as  an  appendix  or  it  can  be  found  in  the  DeltaSD  source  code  which 
can  be  found  at  the  DeltaSD  project  page  (DeltaSDOS).  Depending  on  where 
DeltaSD  has  been  installed,  the  characterbindings.cpp  file  can  be  found  in 
C;\deltaSd\src\python  or  C:\Program  Files\deltaSd\src\python. 

With  the  wrapper  code  written,  now  one  can  call  the  C++  functions 
directly  from  a  Python  script.  Continuing  to  use  the  DeltaSD  character  bindings 
file  as  an  example,  it  is  now  worthwhile  to  look  at  a  sample  Python  script  which 
makes  use  of  the  above  wrapping.  The  following  script  file,  called  animate.py 
will  be  used  to  help  tie  the  prior  concepts  together  (see  Figure  11).  This  script  is 
run  by  running  a  short  test  application  build  with  Visual  Studio  .NET  200S.  The 
application,  called  testPythonChar.exe  creates  a  simple  scene  in  DeltaSD  and 
an  instance  of  the  Python  interpreter.  Because  the  Python  interpreter  is 
interactive,  it  allows  the  running  of  a  script  in  real  time.  In  the  script  one 
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character  runs  in  a  circle  while  the  other  is  walking  in  a  circle.  At  the  same  time, 
the  helicopter  flies  overhead  in  a  tight  circle.  Figure  12  on  page  43  shows  the 
results  of  running  the  sample  C++  application. 


from  dtCore  import  * 
from  dtChar  import  * 
from  math  import  * 
from  time  import  * 

plane  =  Ob ject . Getinstance ( ' helo ' ) 
bob  =  Character . Getinstance ( 'bob ' ) 
dave  =  Character . Getinstance (' dave ' ) 

transform  =  Transform () 

angle  =  0 

def  radians (v) ; 

return  v  *  pi/180 

while  True: 

transform. Set (4  0*cos (radians (angle)  )  , 

100  +  40*sin  (radians (angle) )  , 

20,  angle,  0,  -45) 
plane.SetTransform( transform) 
bob . SetVelocity (0.5) 
bob . SetRotation (angle) 
bob . ExecuteAction ( "walkl " ) 
dave . SetVelocity (30.0) 
dave. SetRotation (-angle) 
dave . ExecuteAction ( "run" ) 
sleep  (0.01) 
angle  +=  0.45 

Figure  1 1 .  Code  from  animate. py 


This  simple  application  creates  a  scene  in  DeltaSD  and  also 
invokes  a  Python  interpreter.  The  interpreter  is  similar  in  some  ways  to  the 
console  found  on  some  common  games  like  Unreal  or  Doom.  For  those  who 
may  be  unfamiliar  with  the  term,  one  can  think  of  the  console  to  be  similar  to 
opening  a  DOS  command  prompt  within  Microsoft  Windows™.  The  console  can 
be  used  for  both  input  and  output.  It  can  be  a  useful  tool  to  help  debug  because 
it  can  display  error  messages.  It  can  also  be  used  to  load  additional  functionality 
into  the  game.  Similarly,  it  is  using  this  Python  interpreter  that  one  can  introduce 
some  new  behavior.  Figure  13  on  the  following  page  shows  a  snapshot  of  the 
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result  of  typing  the  command  execfile(‘animate.py’)  into  the  interpreter.  This 
command  is  what  the  Python  language  uses  to  execute  a  script  file. 
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Figure  13.  Running  the  animate. py  Python  Script 

E.  SUMMARY 

This  chapter  took  a  look  at  scripting  languages,  with  specific  focus  on 
UnrealScript  and  Python.  By  looking  at  the  way  Python  script  is  handled  within 
DeltaSD,  one  gains  a  better  appreciation  for  the  capabilities  a  scripting  language 
brings  to  the  engine.  Because  Python  supports  rapid  prototyping,  the  scripter 
can  test  out  new  Al  behaviors  as  they  are  modified  or  made  available. 
Ultimately,  the  engine  does  not  necessarily  need  to  be  recompiled  each  time  to 
test  out  a  new  function  or  behavior. 

In  addition,  by  showing  that  DeltaSD,  using  the  Boost.Python  libraries,  is 
capable  of  creating  applications.  As  the  engine  matures,  it  is  possible  to 
conceive  of  a  programmer  using  Python  to  build  entire  applications  based  on 
existing  pieces  of  DeltaSD.  It  is  this  flexibility  and  cross  platform  support,  that 
makes  Python  a  suitable  choice  to  create  the  functionality  needed.  Though  there 
is  much  work  to  be  done,  the  capabilities  that  Python  brings  are  promising. 
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V.  CONCLUSIONS  AND  FUTURE  WORK 


A.  INTRODUCTION 

In  this  chapter,  a  summary  of  some  of  the  things  learned  from  looking  at 
current  game  engines  and  available  technologies  is  presented.  In  addition,  some 
recommendations  for  future  work  are  provided. 

B.  CONCLUSION 

Until  recently,  the  game  industry  has  placed  much  of  the  focus  of  the 
development  cycle  on  lavish  computer  graphics  to  increase  the  visual  realism  of 
their  games.  As  was  mentioned  in  the  interview  with  Chris  Butcher  from  Bungie 
(Valdes04),  the  graphical  realism  has  achieved  a  point  where  it  is  not  adding 
much  to  realism  compared  to  the  amount  of  computer  resources  it  uses.  Instead 
of  continuing  down  a  path  of  diminishing  returns,  the  focus  should  change  to  an 
area  that  is  in  need  of  continued  development:  Al.  Whereas  before,  many  game 
development  studios  poured  their  resources  into  graphics  and  other  areas  of  the 
game,  Al  has  begun  to  take  a  larger  role  in  determining  a  game’s  success  in  the 
market.  It  is  not  enough  to  simply  have  graphics  to  create  the  sense  of 
immersion;  the  sense  of  immersion  should  increase  if  the  participant  feels  as  if 
participating  against  some  form  of  intelligence.  The  elusive  part,  to  this  point,  is 
figuring  out  how  to  measure  a  person’s  level  of  immersion. 

Some  of  the  factors  that  have  contributed  to  poor  Al  in  the  past  are  the 
following:  game  developers  not  taking  Al  seriously  and  making  it  a  last  minute 
rush  job;  hardware  constraints,  like  CPU  cycles;  lack  of  appreciation  of  the  nature 
of  game  Al  or  inadequate  understanding  of  how  to  apply  Al  techniques.  In  the 
past,  programmers  did  work  on  all  areas  of  Al  within  a  single  game.  Today  there 
is  now  some  specialization  occurring.  Specifically,  there  are  more  dedicated  Al 
programmers  on  a  given  development  team.  What  dedicated  means  in  this 
instance  is  that,  from  the  start  to  the  finish,  the  programmer  is  focused  on  Al. 
(Tozour02) 
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DeltaSD  has  thus  far  shown  that  it  is  quite  versatile  based  on  the  different 
types  of  sample  environments  and  applications  built  to  date.  From  inside  a  ship 
space  in  the  Fire  Fighter  Trainer  (First  Person  Shooter  perspective)  to  the  FAA 
helicopter  trainer  (Flight  simulator),  DeltaSD  can  handle  both  indoor  and  outdoor 
environments.  However,  none  of  the  work  done  so  far  has  done  much  in 
investigating  the  use  of  Al  in  the  application.  For  the  Fire  Fighter  Trainer,  an 
expert  system  might  be  useful  for  the  after  action  review  to  evaluate  the 
participant’s  performance  in  the  simulation. 

To  recap,  a  final  recollection  of  some  of  the  technologies  discussed 
throughout  this  thesis  is  now  presented  along  with  some  specific 
recommendations  about  how  one  might  incorporate  them  into  the  DeltaSD 
gaming  and  simulation  engine. 


1.  Common  Al  Technologies 

In  Chapter  III,  some  of  the  common  technologies  used  by  commercial 
game  engines  were  covered.  Since  DeltaSD  does  not  have  any  Al  capability  at 
the  moment,  some  or  all  of  the  listed  capabilities  should  be  prioritized  and  added 
to  the  engine. 


a.  State  Machine 

Since  it  is  the  most  common  Al  capability,  the  first  one  should  be 
the  implementation  of  the  State  Machine;  specifically,  the  Finite  State  Machine 
should  be  the  first  to  be  implemented.  Since  the  FSM  is  widely  used,  it  will  be 
most  familiar  to  anyone  attempting  to  develop  a  game.  This  could  be  written  in 
the  Python  script  language  and  later  rolled  into  the  C++  libraries  in  DeltaSD  if 
speed  becomes  an  issue.  A  FSM  should  be  a  basic  building  block  in  the  Al 
capabilities  of  DeltaSD  and  is  probably  one  of  the  smaller  problems  to  tackle. 
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b.  Pathfinding 

Another  common  Al  tool  in  games  is  the  use  of  waypoints  in 
pathfinding.  Anyone  doing  modifications  to  Unreal  or  Half  Life  2  has  likely  used  a 
level  editor  to  place  waypoints  for  the  Al  to  follow.  One  fellow  NPS  student  had 
done  some  work  with  automatic  waypoint  generation.  By  combining  the 
placement  of  waypoints  with  some  simple  line  of  sight  checking,  the  algorithm 
figures  out  which  waypoints  are  accessible  from  each  individual  waypoint.  Then, 
once  this  information  is  available,  the  shortest  path  can  be  found  using  the  A* 
search.  Such  a  capability  needs  to  be  added  into  the  DeltaSD  API.  Though  it  is 
certainly  possible  to  write  this  in  Python,  the  A*  search  will  likely  be  faster  if  it  is 
written  in  C++  and  made  available  as  part  of  the  DeltaSD  API.  Ultimately,  this  is 
a  good  candidate  for  the  basic  Al  functionality  that  is  required. 

c.  Scripting 

The  Python  language  has  already  been  selected  for  scripting. 
Much  of  the  desired  Al  functionality  can  take  advantage  of  Python  and  its  ability 
for  rapid  prototyping.  New  Al  capabilities  can  be  quickly  tested  and  changed  in 
Python,  potentially  reducing  the  development  cycle.  Then,  as  mentioned  in  the 
previous  two  capabilities,  where  speed  becomes  an  issue,  the  desired  Python 
code  can  be  transferred  into  C++. 

2.  Open-Source  Al  Packages 

There  are  two  open-source  engines  in  particular  looked  at  in  this  thesis. 
Past  research  had  indicated  that  both  projects  were  inactive  based  on  date  and 
time  stamps  on  their  respective  SourceForge  project  pages.  However,  the  FEAR 
project  has  just  posted  an  updated  Software  Developer  Kit  (SDK)  recently 
(SmithOS).  The  OpenAI  project  has  not  had  any  active  updates  since  early  last 
year,  while  the  FEAR  project  has  recently  received  a  new  lease  on  life.  Since  the 
FEAR  project  is  based  on  the  use  of  the  Quake  Engine,  the  DeltaSD  team  would 
have  to  look  at  the  SDK  as  it  is  today  with  the  Quake  examples  and  write  their 
own  interface  to  the  FEAR  APIs.  There  is  also  a  question  of  licensing,  where  the 
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FEAR  project  uses  the  General  Public  License  or  GPL,  DeltaSD  uses  the  Limited 
General  Public  License,  or  LGPL.  This  is  not  such  a  problem  as  the  developer 
has  said  that  he  can  grant  licenses  in  LGPL  as  needed  upon  contacting  him. 
Both  projects  would  be  worth  looking  at  for  ideas  on  “rolling  our  own”  but  neither 
can  be  recommended  wholesale. 

3.  Al  Middleware 

Another  area  mentioned  in  Chapter  III  was  Al  Middleware.  For  some 
game  development  studios  with  limited  personnel,  limited  financial  resources  and 
short  deadlines,  using  Al  Middleware  is  certainly  a  viable  option.  Because  there 
are  licensing  costs  and  restrictions  involved,  and  since  the  goal  of  DeltaSD  is  to 
be  open  source  and  freely  available  throughout  the  DoD,  it  is  recommended  that 
such  Al  Middleware  be  avoided  at  this  time  other  than  for  a  point  of  reference  for 
possible  methods  of  implementation. 

4.  Al  and  Animation 

At  the  moment,  ReplicantBody  and  Cal3d  appear  to  be  a  good  fit.  As  the 
Al  develops  through  Python  scripting,  more  animations  to  play  with  will  be 
beneficial.  There  are  only  a  few  basic  animations  available  to  the  Marine  and 
Opfor  characters  currently  available  in  DeltaSD.  More  animations  are  needed  to 
test  out  the  blend  capabilities  to  mix  animations.  Having  exporters  for  the  major 
modeling  applications  such  as  Alias  MAYA  and  Discreet’s  3D  Studio  Max  will 
help  reduce  time  to  produce  new  models  for  use  in  DeltaSD  applications 
(SmithOS).  As  time  progresses,  improvements  in  the  exporters  should  allow 
modelers  to  focus  on  creating  model  content  and  animations.  Ultimately,  this 
would  improve  the  number  of  models  available  for  use  in  DeltaSD  and  create  a 
larger  library  of  animations.  In  the  end,  it  is  important  to  remember  that  Al  and 
animation  are  closely  tied  together.  The  Al  must  be  able  to  correctly  select  an 
appropriate  animation  for  playback  or  the  level  of  realism  may  be  compromised. 
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C.  FUTURE  WORK 

This  thesis  has  touched  on  where  Al  is  today,  but  it  is  important  to  look  at 
where  DeltaSD  should  go  from  here,  specifically  with  respect  to  Al.  Part  of  the 
motivation  of  this  thesis  has  been  to  convey  an  understanding  of  why  Al  is 
important.  Understanding  the  importance  of  Al,  what  are  some  of  the  next 
steps?  What  would  be  a  reasonable  road  map  to  include  Al  in  the  DeltaSD 
engine? 


1.  NPCs  Using  Python  Script 

One  of  the  first  things  that  should  be  attempted  is  to  build  a  NPC  with 
Python  script.  Since  there  is  a  plethora  of  web  sites  dedicated  to  the  modification 
of  Unreal  Tournament,  this  provides  a  good  starting  point  to  begin  building  the 
first  basic  NPC  Al  using  the  Python  language.  Using  the  Bot  class  from  Unreal 
Tournament  as  a  template,  a  similar  structure  could  be  developed  in  the  Python 
language.  This  structure  can  become  one  of  the  basic  Al  building  blocks  in  the 
DeltaSD  engine  and  can  be  a  stepping  stone  to  higher  Al  functions.  Using 
UnrealScript  as  a  model,  the  functionality  that  Epic  Games  has  achieved  would 
be  an  asset  to  the  DeltaSD  toolset.  Already  having  the  graphics  rendering, 
sound  and  physics,  the  NPC  Python  class  or  classes  could  spark  interest  and  get 
the  open  source  community  involved.  Cn  the  DeltaSD  website,  there  has  been 
online  discussion  on  developing  a  game  of  some  type.  Cf  course  a  game  is  only 
one  example,  but  by  demonstrating  that  power  and  flexibility,  further  interest 
would  be  generated  and,  hopefully,  more  developers  would  join  the  cause. 


2.  Interface  with  Production  Systems 

Since  the  DoD  is  interested  in  biologically-inspired  computing  and  more 
closely  modeling  cognition  (DARPA05),  the  ability  to  interface  DeltaSD  to  an 
outside  inference  engine  like  SCAR  or  Clips  might  provide  an  alternative  to 
entirely  writing  Al  from  scratch.  However,  like  many  Al  technologies,  this  is 
context  dependent,  or  put  another  way,  application  dependent.  Cne  possible 
downside  to  this  is  a  developer’s  lack  of  familiarity  with  these  specific  production 
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systems  and  how  they  work.  Similar  to  Figure  2,  the  engine  interfaces  to  the 
production  system  similar  to  the  gamebots  method.  The  world  state  information 
is  passed  into  the  production  system  and  is  stored  in  memory  which  then  allows 
any  rules  to  fire  that  are  satisfied.  Once  the  result  is  available,  it  is  passed  back 
to  the  engine. 


3.  Define  an  Objective  Measure 

Potentially,  one  of  the  hardest  problems  is  coming  up  with  an  objective 
measure  of  immersion  and  intelligence.  Specifically,  how  does  one  objectively 
measure  the  level  of  “realism”  achieved  by  the  Al?  This  becomes  a  human 
factors  problem  and  ultimately  requires  data  collection,  and  in  large  numbers  to 
be  meaningful  or  statistically  significant. 

4.  Cost/Benefit  Analysis 

The  issues  surrounding  cost  of  licensing  the  entire  engine  versus  licensing 
only  part  of  the  software  (Al  Middleware)  versus  going  the  open  source  route 
were  not  explored.  Since  the  licensing  of  the  entire  Unreal  engine  is  quite 
expensive,  how  does  it  compare  to  paying  a  relatively  small  in  house  team  to 
continue  to  research  and  link  together  available  open  source  projects  to  build 
similar  functionality. 

While  it  is  certainly  easy  to  look  strictly  at  the  cost  of  licensing  versus 
paying  a  dedicated  team  to  champion  the  open  source  effort  here  at  NPS,  it  is 
also  important  to  take  a  look  at  the  value  added  by  either  method.  In  the  case  of 
licensing  the  Unreal  Engine,  is  the  cost  worth  the  benefit  of  having  one  of  the 
latest  game  engines?  Or,  does  the  open  source  approach  gain  enough 
momentum  that  creates  a  lot  of  value  added  by  those  who  contribute  their  talents 
and  time?  Due  to  the  intent  of  the  DeltaSD  project  and  what  it  is  trying  to 
achieve,  it  would  appear  that  the  open  source  approach  would  be  more 
economical;  however,  no  in-depth  study  has  been  conducted. 
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5.  Al  on  a  Dedicated  Processor 

In  the  computer  graphics  field,  much  of  the  recent  emphasis  has  been 
using  specialized  graphics  processing  units  or  GPUs  to  offload  the  graphics 
specific  functions  and  calculations  from  the  Central  Processing  Unit  (CPU).  By 
having  dedicated  graphics  processing  hardware,  the  CPU  is  free  to  do  other 
tasks  like  Al  or  Physics.  One  company  has  prepared  a  dedicated  processor  to 
strictly  deal  with  the  idea  of  physics  calculations.  This  dedicated  circuit  card 
removes  some  of  the  burden  on  the  CPU  with  respect  to  all  the  motion 
calculations  required  for  rigid  body  collisions.  Again,  the  end  result  should  free 
up  the  CPU  for  other  tasks  as  necessary.  Currently,  the  card  is  not  yet  available 
as  the  computer  game  industry  hasn’t  fully  accepted  this  idea. 

Similarly,  it  is  conceivable  that  a  custom  processor  card  could  be 
dedicated  to  the  calculations  and  functions  specific  to  the  Al  in  a  game  and 
simulation  engine.  This  dedicated  Al  processor  would  reduce  the  load  on  the 
CPU  and  increase  the  level  of  Al  functionality  that  could  be  built  into  a  game  or 
simulation.  Though  the  GPU  has  been  quite  successful,  at  this  point  it  is  unclear 
that  a  dedicated  Al  processing  unit  will  receive  a  similar  response. 
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